Coordinated suspension of replication groups

ABSTRACT

A target commit sequence number (CSN) to be used to synchronize state information pertaining to an application among nodes of a state replication group (SRG) prior to a suspension of the SRG&#39;s operations is identified. Each node stores a respective commit record set of the application. Some number of SRG nodes suspend operations after synchronizing their local commit records up to the CSN. A configuration manager of the SRG verifies that, subsequent to a suspension of operations at the nodes, at least a threshold number of the nodes are available for service and have updated their commit record sets. The configuration manager then re-activates the SRG.

BACKGROUND

In recent years, more and more computing applications are beingimplemented in distributed environments. A given distributed applicationmay, for example, utilize numerous physical and/or virtualized serversspread among several data centers of a provider network, and may servecustomers in many different countries. As the number of servers involvedin a given application increases, and/or as the complexity of theapplication's network increases, failure events of various types (suchas the apparent or real failures of processes or servers, substantialdelays in network message latency, or loss of connectivity between pairsof servers) are inevitably encountered at higher rates. The designers ofthe distributed applications are therefore faced with the problem ofattempting to maintain high levels of application performance (e.g.,high throughputs and low response times for application requests) whileconcurrently responding to changes in the application configurationstate.

Some traditional techniques for managing state information may involvelocking the state information to implement application state changes ina consistent manner. Unfortunately, the locking mechanisms used forapplication state and/or data can themselves often become performancebottlenecks as the application increases in size and complexity. Othertechniques may avoid locking, but may have to pause normal operations topropagate changed state information among the application's components.Such “stop-the-world” periods may be problematic, however, especiallyfor latency-sensitive applications that are used for mission-criticalworkloads by hundreds or thousands of customers spread in different timezones across the world.

BRIEF DESCRIPTION OF DRAWINGS

FIG. 1 illustrates an example system environment in which a dynamic DAG(directed acyclic graph) of replication nodes is established formanaging application state changes, according to at least someembodiments.

FIG. 2 a-2 h collectively illustrate an example sequence of operationsthat may be performed at a replication DAG in response to a detectionthat one of the nodes of the DAG may have failed, according to at leastsome embodiments.

FIG. 3 illustrates example components of application state records andDAG configuration-delta messages that may be generated at a dynamicreplication DAG according to at least some embodiments.

FIG. 4 illustrates an example replication DAG whose member nodes aredistributed across a plurality of availability containers of a providernetwork, according to at least some embodiments.

FIG. 5 illustrates an example configuration in which nodes of aplurality of replication DAGs may be implemented at a single host in amulti-tenant fashion, according to at least some embodiments.

FIG. 6 is a flow diagram illustrating aspects of operations that may beperformed at an acceptor node of a replication DAG in response toreceiving a state transition request, according to at least someembodiments.

FIG. 7 is a flow diagram illustrating aspects of operations that may beperformed at an intermediate node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments.

FIG. 8 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments.

FIG. 9 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager of a replication DAG, according toat least some embodiments.

FIG. 10 is a flow diagram illustrating aspects of operations that may beperformed at a member node of a replication DAG in response to receivinga configuration-delta message from a configuration manager, according toat least some embodiments.

FIG. 11 a-11 h collectively illustrate an example sequence of operationsthat may be performed at a replication DAG during a coordinatedsuspension procedure, according to at least some embodiments.

FIG. 12 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of a state replication group such as areplication DAG during a coordinated suspension procedure, according toat least some embodiments.

FIG. 13 is a flow diagram illustrating aspects of operations that may beperformed at a non-committer node of a state replication group such as areplication DAG during a coordinated suspension procedure, according toat least some embodiments.

FIG. 14 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager of a state replication group suchas a replication DAG during a coordinated suspension procedure,according to at least some embodiments.

FIG. 15 illustrates an example system environment comprising apersistent change log supporting transactions that may include writes toa plurality of data stores, according to at least some embodiments.

FIG. 16 illustrates an example implementation of a persistent change logusing a replication DAG, according to at least some embodiments.

FIG. 17 illustrates example component elements of a transaction requestdescriptor that may be submitted by a client of a logging service,according to at least some embodiments.

FIG. 18 illustrates an example of read-write conflict detection at alog-based transaction manager, according to at least some embodiments.

FIG. 19 is a flow diagram illustrating aspects of control-planeoperations that may be performed at a logging service, according to atleast some embodiments.

FIG. 20 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction requestreceived from a client, according to at least some embodiments.

FIG. 21 illustrates examples of transaction request descriptors that maybe used to achieve respective special-case consistency objectives,according to at least some embodiments.

FIG. 22 illustrates an example of enforcing a de-duplication constraintassociated with a transaction request received at a log-basedtransaction manager, according to at least some embodiments.

FIG. 23 illustrates an example of enforcing a sequencing constraintassociated with a transaction request received at a log-basedtransaction manager, according to at least some embodiments.

FIG. 24 illustrates an example of a transaction request descriptorcomprising multiple logical constraint descriptors, according to atleast some embodiments.

FIG. 25 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction request thatindicates one or more logical constraints, according to at least someembodiments.

FIG. 26 is a block diagram illustrating an example computing device thatmay be used in at least some embodiments.

While embodiments are described herein by way of example for severalembodiments and illustrative drawings, those skilled in the art willrecognize that embodiments are not limited to the embodiments ordrawings described. It should be understood, that the drawings anddetailed description thereto are not intended to limit embodiments tothe particular form disclosed, but on the contrary, the intention is tocover all modifications, equivalents and alternatives falling within thespirit and scope as defined by the appended claims. The headings usedherein are for organizational purposes only and are not meant to be usedto limit the scope of the description or the claims. As used throughoutthis application, the word “may” is used in a permissive sense (i.e.,meaning having the potential to), rather than the mandatory sense (i.e.,meaning must). Similarly, the words “include,” “including,” and“includes” mean including, but not limited to.

DETAILED DESCRIPTION

Various embodiments of methods and apparatus for managing distributedapplication state using replication nodes organized as a graph, and ofdeploying such graphs to implement a logging service that can be usedfor transaction management, are described. According to someembodiments, a replicated state machine for building a fault-tolerantdistributed application may be implemented using a plurality ofreplication nodes arranged in a directed acyclic graph (DAG). In someimplementations, a particular replication DAG may include one or moreacceptor nodes, one or more committer nodes, zero or more intermediarynodes each positioned along a replication pathway comprising DAG edgesleading from an acceptor node to a committer node, and zero or morestandby nodes that are configured to quickly take over responsibilitiesof one of the other types of nodes in the event of a node failure.Acceptor, intermediary and standby nodes of a replication DAG maycollectively be referred to as “non-committer” nodes herein. “Acceptor”,“intermediary”, “committer”, and “standby” may be referred tocollectively as the set of roles that a DAG node may assume. In someembodiments, acceptor nodes may also be referred to as “head” nodes ofthe DAG, and committer nodes may also be referred to as “tail” nodes.

In general, in at least some embodiments, each node of a particularreplication DAG may be responsible for replicating state information ofat least a particular application, e.g., in the form of state transitionrecords written to a local disk or other similar storage device.Application state information may be propagated along a set of edgesfrom an acceptor node to a committer node of the DAG, referred to hereinas a replication pathway or a commit pathway. Each state transitionmessage propagated within the DAG may include a respective sequencenumber or a logical timestamp that is indicative of an order in whichthe corresponding state transition request was processed (e.g., at anacceptor node). Sequence numbers may be implemented using any of avariety of techniques in different embodiments—e.g., a simple N-bitcounter maintained by an acceptor node may be used, or a monotonicallyincreasing logical timestamp value (not necessarily related to atime-of-day clock) generated by an administrative component of the DAGsuch as the DAG's configuration manager may be used. When a particularstate transition record reaches a committer node, e.g., after asufficient number of replicas of the state transition record have beensaved along a replication pathway, the transition may be explicitly orimplicitly committed. The state of the application as of a point in timemay be determined in some embodiments as a logical accumulation of theresults of all the committed state transitions up to a selected sequencenumber. A configuration manager may be responsible for managing changesto DAG configuration (e.g. when nodes leave the DAG due to failures, orjoin/re-join the DAG) by propagating configuration-delta messagesasynchronously to the DAG nodes as described below. In some embodiments,each replication node may implement a respective deterministic finitestate machine, and the configuration manager may implement anotherdeterministic finite state machine. The protocol used for managing DAGconfiguration changes may be designed to maximize the availability or“liveness” of the DAG in various embodiments. For example, the DAG nodesmay not need to synchronize their views of the DAG's configuration in atleast some embodiments; thus, the protocol used for application statetransition processing may work correctly even if some of the nodes alonga replication pathway have a different view of the current DAGconfiguration than other nodes. It may thus be the case, in one simpleexample scenario, that one node A of a DAG continues to perform itsstate transition processing responsibilities under the assumption thatthe DAG consists of nodes A, B, C and D in that order (i.e., with areplication pathway A-to-B-to-C-to-D), while another node D has alreadybeen informed as a result of a configuration-delta message that node Chas left the DAG, and has therefore updated D's view of the DAG ascomprising a changed pathway A-to-B-to-D. The configuration manager maynot need to request the DAG nodes to pause processing of statetransition nodes in at least some embodiments, despite the potentiallydivergent views of the nodes regarding the current DAG configuration.Thus, the types of “stop-the-world” configuration synchronizationperiods that may be required in some state replication techniques maynot be needed when using replication DAGs of the kind described herein.

Under most operating conditions, the techniques used for propagating DAGconfiguration change information may eventually result in a convergedconsistent view of the DAG's configuration at the various member nodes,while minimizing or eliminating any downtime associated with nodefailures/exits, node joins or node role changes. Formal mathematicalproofs of the correctness of the state management protocols may beavailable for at least some embodiments. In at least some embodiments,the replication DAG's protocols may be especially effective in dealingwith false-positive failure detections. For example, in the aboveexample, node D may have been informed by the configuration manager thatnode C has failed, even though node C has not actually failed. Thus,state transitions may still be processed correctly by C (and by itsneighbors B and D) for some time after the false positive failuredetection, in the interval before the configuration-delta messagesindicating C's exit are received at A, B and D, enabling the applicationwhose state is being replicated to make progress despite thefalse-positive failure detection. Upon eventually being informed that ithas been removed from the DAG, C may indicate to the configurationmanager that it is in fact available for service, and may be allowed tore-join the DAG (e.g., as a standby node or in some other position alongthe modified replication pathway).

In some embodiments, an acceptor node may be responsible for receivingapplication state transition requests from a client of the replicationDAG, determining whether a particular requested transition should beaccepted for eventual commit, storing a local replica of an acceptedstate transition record, and transmitting accepted state transitionrecords to a neighbor node along a replication pathway of the DAGtowards a committer node. Depending on the use case, a state transitionrecord may include a write payload in some embodiments: e.g., if theapplication state comprises the contents of a database, a statetransition record may include the bytes that are written during atransaction corresponding to the state transition. The acceptor node mayalso be responsible in at least some embodiments for determining orgenerating the sequence number for an accepted state transition. Anintermediary node may be responsible for storing a local replica of theaccepted state transition record, and transmitting/forwarding a messageindicating the accepted state transition to the next node along thepathway to a committer node. The committer node may store its ownreplica of the state transition record on local storage, e.g., with anindication that the record has been committed. A record indicating thata corresponding state transition has been committed may be referred toherein as a “commit record”, while a record that indicates that acorresponding state transition has been accepted but has not yetnecessarily been committed may be referred to as an “accept record”. Insome embodiments, and depending on the needs of the application, thecommitter node may initiate transmission of a commit response (e.g., viathe acceptor node) to the client that requested the state transition. Inat least one embodiment, the committer node may notify some or all ofthe nodes along the replication pathway that the state transition hasbeen committed. In some embodiments, when an indication of a commit isreceived at a DAG node, the accept record for the now-committed statetransition may be replaced by a corresponding commit record, or modifiedsuch that it now represents a commit record. In other embodiments, agiven DAG node may store both an accept record and a commit record forthe same state transition, e.g., with respective sequence numbers. Insome implementations, separate commit record sets and accept record setsmay be stored in local storage at various DAG nodes, while in otherimplementations, only one type of record (accept or commit) may bestored at a time for a given state transition at a given DAG node.

A configuration manager may be designated as the authoritative source ofthe DAG's configuration information in some embodiments, responsible foraccepting changes to DAG configuration and propagating the changes tothe DAG nodes. In at least some embodiments, the configuration managermay itself be designed to be resilient to failures, e.g., as afault-tolerant cluster of nodes that collectively approve DAGconfiguration changes (such as removals or additions of nodes) viaconsensus and replicate the DAG configuration at a plurality ofconfiguration manager storage devices. As implied by the name“configuration-delta”, a message sent to a DAG node by the configurationmanager may include only an indication of the specific change (e.g., achange caused by a node joining the DAG or leaving the DAG, or a changeto a role/position of an existing node of the DAG), and need not includea representation of the DAG's configuration as a whole, or list theentire membership of the DAG. A given recipient of a configuration-deltamessage may thus be expected to construct its own view of the DAGconfiguration, based on the specific set or sequence ofconfiguration-delta messages it has received thus far. In someimplementations, sequence numbers may also be assigned toconfiguration-delta messages, e.g., to enable a recipient of aconfiguration-delta message to determine whether it has missed anyearlier configuration-delta messages. Since the configuration managermay not attempt to guarantee the order or relative timing of receivingthe configuration-delta messages by different DAG nodes, the currentviews of the DAG's configuration may differ at different nodes in someembodiments, at least for some periods of time as indicated by theexample above.

According to one embodiment, the actions taken by DAG nodes in responseto configuration-delta messages may differ based on whether theconfiguration change affects an immediate neighbor of the recipient.Consider another example scenario in which a DAG comprises an acceptornode A, an intermediary node B, and a committer node C at a point oftime T0, with the initial replication pathway A-to-B-to-C. At a time T1,the DAG's configuration manager DCM1 becomes aware that B has left theDAG, e.g., as a result of an apparent failure or loss of connectivity.DCM1 may send respective asynchronous configuration-delta messages D1and D2 respectively to remaining nodes A and C, without requesting anypause in state transition request processing. If C receives D2 at timeT2, before A receives D1 at time T3, A may continue sending statetransition messages directed to B for some time interval (T3-T2)(although, if N has in fact failed, the messages send by A may not beprocessed by B). Similarly, if A receives D1 at T2, before C receives D2at T3, C may continue to process messages it receives from B that werein flight when B failed, for some time (T3-T2) before C becomes aware ofB's departure from the DAG. When node A receives D1, if it has not yetbeen contacted by C, node A may establish connectivity to C as its newimmediate successor in the newly-configured replication pathway (A-to-C)that replaces the older replication pathway (A-to-B-to-C). Similarly,when C receives D2, it may establish connectivity to A (if A has notalready contacted C) as its new immediate predecessor, and at least insome embodiments, C may submit a request to A for re-transmissions ofstate transition records that may have been transmitted from A to B buthave not yet reached C. For example, C may include, within there-transmission request, the highest sequence number HSN1 of a statetransition record that it has received thus far, enabling A tore-transmit any state transition records with sequence numbers higherthan HSN1.

In at least some embodiments, the configuration manager may rely on ahealth detection mechanism or service to indicate when a DAG node hasapparently become unhealthy, leading to a removal of theapparently-unhealthy node from the DAG configuration. At least somehealth detection mechanisms in distributed environments may depend onheartbeats or other lower-level mechanisms which may not always make theright decisions regarding node health status. At the same time, theconfiguration manager may not be in a position to wait indefinitely toconfirm actual node failure before sending its configuration-deltamessages; instead, it may transmit the configuration-delta messages upondetermining that the likelihood of the node failure is above somethreshold (e.g., 80% or 90%), or use some other heuristics to triggerthe DAG configuration changes and corresponding delta messages. Asmentioned earlier, the state management protocols used at thereplication DAG may alleviate the negative impact of false positivefailure “detections”, e.g., by avoiding “stop-the-world” pauses. As aresult, it may be possible to use faster/cheaper (although potentiallyless reliable) failure-checking mechanisms when replication DAGs areemployed than would have been acceptable if other state replicationtechniques were used.

In at least one embodiment, a coordinated suspension technique may beimplemented for replication DAGs. Under certain conditions, e.g., if alarge-scale failure event involving multiple DAG resources or nodes isdetected, the configuration manager may direct the surviving nodes ofthe DAG to stop processing further state transitions, synchronize theirapplication state information with each other, store the synchronizedapplication state information at respective storage locations, and awaitre-activation instructions. In some implementations, after savingapplication state locally, the DAG nodes may each perform a cleanshutdown and restart, and report to the configuration manager afterrestarting to indicate that they are available for service. If a nodethat had failed before the suspend command was issued by theconfiguration manager reports that it is available for service, in someembodiments the configuration manager may direct such a node tosynchronize its application state with another node that is known (e.g.,by the configuration manager) to be up-to-date with respect toapplication state. The configuration manager may wait until a sufficientnumber of nodes are (a) available for service and (b) up-to-date withrespect to application state, determine a (potentially new) DAGconfiguration, and re-activate the DAG by sending re-activation messagesindicating the DAG configuration to the member nodes of theconfiguration. Such a controlled and coordinated suspension/restartstrategy may allow more rapid and dependable application recovery afterlarge-scale failure events than may have been possible otherwise in someembodiments. The coordinated suspension approach may also be used forpurposes other than responding to large-scale failures—e.g., for fastparallel backups/snapshots of application state information from aplurality of the replication nodes.

DAG-based replicated state machines of the type described above may beused to manage a variety of different applications in variousembodiments. In some embodiments, a logging service may be implemented,at which one or more data stores (e.g., relational or non-relationaldatabases) may be registered for transaction management via an instanceof a persistent change log implemented using a replication DAG. Asdescribed below in further detail, an optimistic concurrency controlmechanism may be used by such a log-based transaction manager in someembodiments. A client of the logging service may perform read operationson one or more source data stores and determine one or more data storelocations to which write operations are to be performed (e.g., based onthe results of the reads) within a given transaction. A transactionrequest descriptor including representations of the read sets, writesets, concurrency control requirements, and/or logical constraints onthe transaction may be submitted to a conflict detector of the loggingservice (e.g., conflict detection logic associated with an acceptor nodeof the corresponding replication DAG). The conflict detector may userecords of previously-committed transactions together with the contentsof the transaction descriptor to determine whether the transactionrequest is acceptable for commit. If a transaction is accepted forcommit, a replication of a corresponding commit record may be initiatedat some number of replication nodes of the DAG established for the log.The records inserted into a given replica of the log may thus eachrepresent respective application state transitions. A number ofdifferent logical constraints may be specified in different embodiments,and enforced by the log-based transaction manager, such asde-duplication requirements, inter-transaction commit sequencingrequirements and the like. Such a log-based transaction managementmechanism may, in some embodiments, enable support for multi-itemtransactions, or multi-database transactions, in which for example agiven transaction's write set includes a plurality of write locationseven though the underlying data stores may not natively supportatomicity for transactions involving more than one write. The writescorresponding to committed transactions may be applied to the relevantdata stores asynchronously in at least some embodiments—e.g., a recordthat a transaction has been committed may be saved in the persistentchange log at some time before the corresponding writes are propagatedto the targeted data stores. The persistent change log may thus becomethe authoritative source of the application state in at least someembodiments, with the data stores catching up with the application stateafter the log has recorded state changes.

Replication DAGs may also be used for replicated database instances, formanaging high-throughput data streams, and/or for distributed lockmanagement in various embodiments. In some embodiments, replication DAGsmay be used within provider networks to manage state changes tovirtualized resources such as compute instances. In at least someembodiments, in addition to propagating committed writes to registereddata stores (from which the results of the writes can be read via therespective read interfaces of the data stores), a logging service mayalso define and implement its own separate access interfaces, allowinginterested clients to read at least a portion of the records stored fora given client application directly from a persistent log instance.

Example System Environment

FIG. 1 illustrates an example system environment in which a dynamic DAG(directed acyclic graph) of replication nodes is established formanaging application state changes, according to at least someembodiments. As shown, in system 100, replication DAG 140 establishedfor managing state transitions of an application 160 comprises areplication pathway with three nodes: an acceptor node 110, anintermediate node 112 and a committer node 114. In addition, DAG 140includes a standby node 130 in the depicted embodiment, available totake over the responsibilities of any of the other nodes if needed.Other combinations of nodes may be deployed for other replicationDAGs—e.g., more than one intermediate node may be used for someapplications, no intermediate nodes may be used for other applications,or standby nodes may not be established. Changes to the configuration ofthe DAG 140 may be coordinated by a fault-tolerant DAG configurationmanager (DCM) 164 as described below.

The acceptor node 110 may receive application state transition requests(STRs) 150 via one or more programmatic interfaces such as APIs(application programming interfaces) in the depicted embodiment. Theacceptor node 110 may accept a requested transition for an eventualcommit, or may reject the request, using application-dependent rules orlogic. If a transition is accepted, a sequence number may be generatedby the acceptor node 110, e.g., indicative of an order in which thattransition was accepted relative to other accepted transitions. Asmentioned above, in some embodiments the sequence number may comprise acounter that is incremented for each accepted transition, while in otherembodiments a logical clock or timestamp value provided by theconfiguration manager may be used. A collection 176A of applicationstate records (ASRs) 172A including corresponding sequence numbers maybe stored in local persistent storage by the acceptor node. In someembodiments, the application state records may comprise both transitionaccept records and transition commit records (with a commit record beingstored only after the acceptor node is informed that the correspondingtransition was committed by the committer node). In other embodiments,at least some nodes along the replication pathway may only store acceptrecords. After storing a state transition record indicating acceptance,the acceptor node may transmit a state transition message (STM) 152Aindicating the approval to its successor node along the replicationpathway, such as intermediate node 112 in the illustrated configuration.The intermediate node may store its own copy of a corresponding ASR,172B, together with the sequence number, in its local ASR collection176B. The intermediate node may transmit its own STM 152B to itsneighbor along the current replication pathway, e.g., to committer node114 in the depicted embodiment. In at least some implementations, theSTMs 152 may include an indication of which nodes have already storedreplicas of the ASRs—e.g., the message 152B may indicate to thecommitter node that respective replicas of the application state recordindicating acceptance have been stored already at nodes 110 and 112respectively.

In response to a determination at the committer node that a sufficientnumber of replicas of the application state record have been stored(where the exact number of replicas that suffice may be a configurationparameter of the application 160), the transition may be committed. TheASR collection 176C of the committer node may comprise records oftransaction commits (as opposed to approvals) in the depictedembodiment; thus, ASR 172C may indicate a commit rather than just anacceptance. In at least some embodiments, the committer node 116 maytransmit indications or notifications to the acceptor node and/or theintermediate node indicating that the transition was committed. In otherembodiments, the acceptor and/or intermediate node may submit requests(e.g., periodically) to the committer node 116 to determine whichtransitions have been committed and may update their ASR collectionsaccordingly. For some applications, explicit commits may not berequired; thus, no indications of commits may be stored, and each of theDAG nodes along the pathway may simply store respective applicationstate records indicating acceptance. In the depicted embodiment,post-commit STMs 154 may be transmitted from the committer node to thestandby node 130 to enable the standby node to update its ASR collection176D (e.g., by storing a commit ASR 172D), so that if and when thestandby node is activated to replace another DAG node, its applicationstate information matches that of the committer node. The fact thatstandby nodes are kept up-to-date with the latest committed applicationstate may enable the configuration manager to quickly activate a standbynode for any of the other three types of roles in some embodiments:e.g., as an acceptor node, an intermediate node, or a committer node.

A fault-tolerant DAG configuration manager (DCM) 164 may be responsiblefor propagating changes to the DAG configuration or membership in theform of configuration-delta messages 166 (e.g., messages 166A, 166B,166C and 166D) to the DAG nodes as needed in the depicted embodiment.When a given DAG node leaves the DAG 140, e.g., as a result of afailure, a corresponding configuration-delta message 166 may be sent toone or more surviving nodes by the DCM 164, for example. Similarly, whena new node joins the DAG (e.g., after a recovery from a failure, or toincrease the durability level of the application 160), a correspondingconfiguration-delta message indicating the join event, the position ofthe joining node within the DAG, and/or the role (e.g., acceptor,intermediate, committer, or standby) granted to the joining node may betransmitted by the DCM to one or more current member nodes of the DAG.The configuration-delta messages 166 may be asynchronous with respect toeach other, and may be received by their targets in any order withoutaffecting the overall replication of application state. Each node of theDAG may be responsible for constructing its own view 174 of the DAGconfiguration based on received configuration-delta messages,independently of the configuration views 174 that the other nodes mayhave. Thus, for example, because of the relative order and/or timing ofdifferent configuration-delta messages received at respective nodes 110,112, 114 and 130, one or more of the configuration views 174A, 174B,174C and 174D may differ at least for some short time intervals in someembodiments. In at least some embodiments, each DAG node may storerepresentations or contents of some number of the configuration-deltamessages received in respective local configuration change repositories.In the depicted embodiment, the DCM 164 may not enforce stop-the-worldpauses in application state processing by the DAG nodes—e.g., it mayallow the nodes to continue receiving and processing application statetransition messages regardless of the timing of configuration-deltamessages or the underlying DAG configuration changes. Examples of themanner in which DAG nodes respond to configuration-delta messages arediscussed below with reference to FIG. 2 a-2 h.

It is noted that although FIG. 1 shows a DAG with a single linearreplication pathway or “chain” with one node of each type, in at leastsome embodiments a replication DAG may include branched pathways and/ormultiple nodes for each role. That is, several acceptor, intermediate,committer and/or standby nodes may coexist in the same DAG, and theDAG's replication pathways may include join nodes (nodes at whichtransition requests from multiple predecessor nodes are received) orsplit nodes (nodes from which transition requests are sent to multiplesuccessor nodes). If either the acceptor node 110 or the committer node116 rejects a requested state transition (e.g., either because theacceptor node determines a set of application-specific acceptancecriteria are not met, or because an insufficient number of replicas ofan accepted transition have been made by the time the committer nodereceives the accepted state transition request message), in someembodiments the client that requested the transition may be informedthat the transition was not committed. The client may then retry thetransition (e.g., by submitting another state transition request), ormay decide to abandon the request entirely. In some implementations,intermediate nodes may also be permitted to abort transition requests.

FIG. 2 a-2 h illustrate an example sequence of operations that may beperformed at a replication DAG in response to a detection that one ofthe nodes of the DAG may have failed, according to at least someembodiments. FIG. 2 a shows an initial state of the DAG configuration,including three nodes 202A, 202B and 202C. State transition requests(STRs) 150 are received at node 202A. Accepted state transition recordsare replicated at nodes 202A (after local approval of the STRs) and 202B(after node 202B receives approved STMs 211A), and committed at 202C(after node 202C receives approved STMs 211B). The DCM 164 may receive ahealth status update 250 indicating that node 202B has apparentlyfailed. The health status update regarding node 202B's status may bereceived from any of a variety of sources in different embodiments,e.g., from one of the other nodes (202A or 202B), or from a healthmonitoring service external to the DAG (e.g., a general-purpose resourcehealth monitoring service established at a provider network where theDAG nodes are instantiated). In at least one implementation, the healthstatus update may be generated by a subcomponent of the DMC 164 itself,such as a monitoring process that periodically sends heartbeat messagesto the DAG nodes and determines that a given node is in an unhealthystate if no response is received within an acceptable time window tosome number of successive heartbeat messages.

In the depicted embodiment, the DCM 164 may decide on the basis of thehealth status update that node 202B should be removed from the DAG, anda new node 202D should be added as a successor to node 202C. The newnode may, for example, comprise a standby node being promoted to activestatus as the new committer node of the DAG. After deciding the newconfiguration of the DAG (i.e., that the DAG should now comprise areplication chain 202A-to-202C-to-202D), and saving a representation ofthe new configuration in a persistent repository, DCM 164 may issue acommand 241 to node 202D to join the DAG as a successor to node 202C. Itis noted that at least in some embodiments, a removal of a node such as202B from a DAG may not necessarily be accompanied by an immediateaddition of a replacement node (especially if the number of DAG nodesthat remain online and connected after the removal exceeds the minimumnumber of nodes needed by the application whose state is beingreplicated); the addition of node 202D is illustrated simply as one ofthe ways in which the DCM may respond to a node failure (or at least anapparent node failure). As shown in FIG. 2 b, it may be the case thatnode 202B has not actually failed (i.e., that the health update was inerror regarding 202B's failure). In such a false-positive scenario,state transition messages may continue to be transmitted from 202Atowards 202B, and from 202B to 202C, allowing the application tocontinue making progress for at least some time after the DCM 164 makesthe removal decision.

In at least some embodiments, when a node such as 202B is removed from aDAG, and the immediate successor (e.g., 202C) of the removed noderemains in the DAG, the role that was previously assigned to the removednode may be transferred to the immediate successor. Thus, node 202C,which may have been a committer node, may be made an intermediate nodeupon node 202B's departure, and the newly-activated node 202D may bedesignated as the new committer node. If the removed node had noimmediate successor (e.g., if node 202C had been removed in the depictedexample instead of node 202B), the newly-activated standby node may begranted the role that was assigned to the removed node in someembodiments. In other embodiments, roles may not be transferred in asuch a sequential/linear fashion—e.g., the configuration manager maydecide which roles should be granted to a given node without taking therelative position of the node vis-à-vis a removed node into account.

After deciding that node 202B should be removed from the DAG, the DCM164 may send respective asynchronous configuration-delta messages 242Aand 242B to nodes 202A and 202C in the depicted embodiment. As shown,each of the delta messages may indicate that 202B has left the DAG, andthat 202D has joined. Although the two changes to the configuration areindicated in a single configuration-delta message in the depictedembodiment, in other embodiments separate configuration delta messagesmay be sent for the removal of 202B and the join of 202D. Theconfiguration-delta messages may indicate only the changes to the DAGconfiguration, and may not comprise a representation of the DAG's entireconfiguration in the depicted embodiment. Until node 202A receives theconfiguration-delta message 242A or otherwise becomes aware that 202Bhas left the DAG (e.g., due to termination of a network connection),STMs may continue to be directed from node 202A to node 202B. In thescenario where 202B has not actually failed, node 202B may continueprocessing state transition requests and sending messages 211B towardsnode 202C until it becomes aware that it has been removed from the DAG(e.g., if either 202A or 202C stop communicating with 202B).

Since the configuration-delta messages 242 are sent using anasynchronous messaging mechanism, they may arrive at their destinationsat different times. If node 202A receives configuration-delta message242A before node 202C receives configuration-delta message 242B, thescenario depicted in FIG. 2 d may be reached (in which the DAG at leasttemporarily contains a branch). In response to message 242A, node 202Amay save the indication of the configuration change in local storage andstop sending any further messages to node 202B. Furthermore, node 202Amay determine that its new successor node is 202C, and may thereforeestablish network connectivity with node 202C and start sending node202C new state transition messages 211C. In the embodiment depicted,state transition processing activities may continue at various nodes ofthe DAG even as the message indicating the removal of 202B makes its wayto the remaining nodes. In a scenario in which node 202B is assumed tohave failed but in fact remains functional, for example, even after node202A learns that node 202B has been removed from the DAG, one or morein-flight state transition messages may be received from node 202A atnode 202B. Upon receiving such an in-flight message, node 202B mayreplicate the state transition information indicated in the message inlocal storage and attempt to transmit another similar STM to node 202C.If node 202C has not yet learned of node 202B's removal (or at least hasnot yet closed its connection with node 202B), node 202C may receive andprocess the message from node 202B, allowing the application to makeprogress, even though node 202B has been removed from the DAGconfiguration by the configuration manager.

If node 202C receives configuration-delta message 242B before node 202Areceived configuration-delta message 242A, the scenario illustrated inFIG. 2 e may be reached. Upon receiving message 242B, node 202C may stopreceiving new messages sent from node 202B (e.g., by terminating itsconnection with node 202B if the connection is still in service). Uponrealizing that node 202A is its new immediate predecessor in the DAGpathway, node 202C may establish connectivity to node 202A. Node 202Cmay also determine the highest sequence number HSN1 (from among thesequence numbers for which approved STMs have already been received atnode 202C), and send a request 260 to node 202A to re-transmit anyapproved state transition messages that 202C may have missed (i.e., anyapproved STMs with higher sequence numbers than HSN1) in the depictedembodiment. Furthermore, node 202C may also establish connectivity toits new successor node 202D, and may start sending subsequent approvedSTMs 211D to node 202D.

After both nodes 202A and 202C have been informed about the DAGconfiguration change, the DAG's new replication pathway illustrated inFIG. 2 f (i.e., 202A-to-202C-to-202D) may be used for new incoming statetransition requests. It is noted that because of the timing of theconfiguration-delta messages 242, it may be the case that node 202Alearns about the configuration change from node 202C before theconfiguration-delta message 242A is received at node 202A. Similarly,node 202C may learn about the new configuration from node 202A (or evennode 202D) in some embodiments. Thus, there may be multiple ways inwhich information about the new configuration may reach any given nodeof the DAG, and at least in some embodiments the DAG nodes may startusing portions of the new replication pathway even before theconfiguration-delta messages have reached all of their targetedrecipients.

As shown in FIG. 2 g, at some point after it has been removed from theDAG (e.g., either due to an actual failure or due to a false positivefailure detection), node 202B may optionally indicate to the DCM 164that it is ready for service. In the case of an actual failure, forexample, node 202B may eventually be repaired and restarted and mayperform some set of recovery operations before sending the “availablefor service” message 280. In the case of a network connectivity loss,the “available for service” message may be sent after connectivity isreestablished. In response, in the depicted embodiment, the DCM 164 maydecide to add node 202B back as a standby node of the DAG. Accordingly,as shown in FIG. 2 h, the DCM may send a join command 282 to node 202B,and a new set of configuration-delta messages 244A, 244B and 244C tonodes 202A, 202B and 202D respectively to inform them of the addition ofnode 202B. It is noted that the sequence of operations illustrated inFIG. 2 a-2 h is provided as an example, and that the DAG nodes and theDCM may perform a different sequence of operations than that illustratedin FIG. 2 a-2 h in response to an apparent failure of node 202B invarious embodiments. For example, no new node may be added to the DAG insome embodiments as a successor to node 202C. Also, in some embodiments,node 202B may not necessarily re-join the same DAG after it becomesavailable for service; instead, for example, it may be deployed to adifferent DAG or may be kept in a pool of nodes from which new DAGs maybe configured.

Although a detection of a failure is shown as triggering a DAGconfiguration changes in FIG. 2 a-2 h, in general, any of a number ofdifferent considerations may lead to modifications of DAG configurationsin various embodiment. For example, an application owner (or the DCM)may decide to add a node to a DAG to enhance data durability or foravailability reasons. Configuration-delta messages indicating theaddition of a new node may be propagated in a similar asynchronousfashion to other DAG nodes as the removal-related propagation describedabove in some embodiments, without requiring “stop-the-world” pauses instate transition processing. A DAG node may have to be taken offline formaintenance-related reasons in some embodiments, e.g., for a softwareupgrade, for debugging software errors, or for hardware modifications.In at least one embodiment, a DAG's configuration may be changed as aresult of a determination that the workload level (e.g., the number ofstate transitions being processed per second) at one or more of thenodes has reached a threshold level, and that more performant (or lessperformant) hardware/software stacks should be utilized than are beingused currently. In some embodiments, a DAG configuration change mayinvolve changing the position or role of a particular DAG node, withoutnecessarily adding or removing a node. For example, a configurationmanager may switch the role of committer to a node that was previouslyan intermediate node, and make the old committer node an intermediatenode in the new configuration. Such a role change may be implemented(and the corresponding configuration-delta messages propagated), forexample, for load balancing purposes, especially in a multi-tenantenvironment in which the same host is being used for nodes of severaldifferent DAGs. Such multi-tenant environments are described below infurther detail.

State Transition Records and Configuration-Delta Messages

FIG. 3 illustrates example components of application state records(ASRs) and DAG configuration-delta messages that may be generated at adynamic replication DAG according to at least some embodiments. Asindicated earlier, copies of application state records, eachrepresenting an approved or committed state transition, may be stored ateach of several nodes along a replication pathway of a DAG in at leastsome embodiments Application state records may also be referred to asstate transition records herein. As shown, an application state record320 may comprise an indication of the type 302 of the transition—e.g.,whether an approval of a requested state transition is being recorded,or whether a commit of an approved state transition is being recorded.In some embodiments, as noted earlier, each DAG node may store bothapproval and commit records, while in other embodiments, only one typeof state transition record may be stored. For example, in one scenario,approval records may be replicate initially at non-committer nodes, andthe approval records may be changed to commit records after thetransaction is eventually committed by the committer node. In at leastone embodiment, a separate transition type field 302 may not be includedin an ASR or in the message that leads to the generation of theASR—instead, the type of the transition may be inferred by a DAG nodebased on the node's knowledge of its current role and/or the role of thesource DAG node from which the message is received. For example, anon-committer node that receives a state transition message may inferthat the message represents an approved state transition.

The state transition records 320 records may include transition data 304in the depicted embodiment. The nature of the contents of the transitiondata component 304 may differ depending on the application whose stateis being managed. In some cases, for example, a state transition requestmay include a write payload (indicating some number of bytes that are tobe written, and the address(es) to which the bytes are to be written),and the write payload may be included in the transition record. Forother applications, each state transition may indicate a respectivecommand issued by an application client, and a representation of thecommand may be included in the ASR. The ASR 320 may also include asequence number 306 (which may also be considered a logical timestamp)corresponding to the state transition. The sequence number may, forexample, be generated at an acceptor node when a state transitionrequest is approved, or at a committer node when the state transition iscommitted. In at least some embodiments, the current state of theapplication being managed using the DAG may be determined by applying,starting at some initial state of the application, transition data ofcommitted state records (e.g., write payloads, commands, etc.) in orderof increasing sequence numbers. In some embodiments, replication historyinformation 308 of a transition may also be included in an ASR—e.g.,indicating which DAG nodes have already stored a respective ASR for thesame transition, and/or the order tin which those records have beenreplicated. Such replication history information may, for example, beused by a committer node in some implementations to confirm that asufficient number of nodes have recorded a given state transition for acommit. In some embodiments, an ASR message may indicate the identity ofthe acceptor node where the corresponding state transition request wasreceived, but need not include information regarding other nodes alongthe replication pathway. In at least one implementation, a committernode may not be required to confirm that a sufficient number of nodeshave replicated a state transition record before committing an approvedstate transition.

A DAG configuration-delta message 370 may indicate an identifier 352 ofthe node (or nodes) joining or leaving the configuration in the depictedembodiment, and the type of change 354 (e.g., join vs. leave) beingimplemented. In some implementations, role information 356 about thejoining (or leaving) node may optionally be included in theconfiguration-delta message. In at least some embodiments, just asapplication state sequence numbers are associated with application statetransitions, DAG configuration change sequence numbers 358 may beincluded with configuration-delta messages. Such sequence numbers may beused by a recipient of the configuration-delta messages to determinewhether the recipient has missed any prior configuration changes, forexample. If some configuration changes have been missed (due to networkpackets being dropped, for example), the recipient node may send arequest to the DCM to re-transmit the missed configuration-deltamessages. The configuration change sequence numbers 358 may beimplemented as counters or logical timestamps at the DCM in variousembodiments. In some implementations in which the DCM comprises acluster with a plurality of nodes, a global logical timestamp maintainedby the cluster manager may be used as a source for the configurationchange sequence numbers 358.

Replication DAG Deployments in Provider Network Environments

FIG. 4 illustrates an example replication DAG whose member nodes aredistributed across a plurality of availability containers of a providernetwork, according to at least some embodiments. Networks set up by anentity such as a company or a public sector organization to provide oneor more services (such as various types of multi-tenant and/orsingle-tenant cloud-based computing or storage services) accessible viathe Internet and/or other networks to a distributed set of clients maybe termed provider networks herein. At least some provider networks mayalso be referred to as “public cloud” environments. A given providernetwork may include numerous data centers hosting various resourcepools, such as collections of physical and/or virtualized computerservers, storage devices, networking equipment and the like, needed toimplement, configure and distribute the infrastructure and servicesoffered by the provider. Within large provider networks, some datacenters may be located in different cities, states or countries thanothers, and in some embodiments the resources allocated to a givenapplication may be distributed among several such locations to achievedesired levels of availability, fault-resilience and performance.

In some embodiments a provider network may be organized into a pluralityof geographical regions, and each region may include one or moreavailability containers, which may also be termed “availability zones”.An availability container in turn may comprise one or more distinctphysical premises or data centers, engineered in such a way (e.g., withindependent infrastructure components such as power-related equipment,cooling equipment, and/or physical security components) that theresources in a given availability container are insulated from failuresin other availability containers. A failure in one availabilitycontainer may not be expected to result in a failure in any otheravailability container; thus, the availability profile of a givenphysical host or virtualized server is intended to be independent of theavailability profile of other hosts or servers in a differentavailability container.

One or more nodes of a replication DAG may be instantiated in adifferent availability container than other nodes of the DAG in someembodiments, as shown in FIG. 4. Provider network 402 includes threeavailability containers 466A, 466B and 466C in the depicted embodiment,with each availability container comprising some number of node hosts410. Node host 410A of availability container 466A, for example,comprises a DAG node 422A, local persistent storage (e.g., one or moredisk-based devices) 430A, and a proxy 412A that may be used as a frontend for communications with DAG clients. Similarly, node host 410B inavailability container 466B comprises DAG node 422B, local persistentstorage 430B, and a proxy 412B, and node host 410C in availabilitycontainer 466C includes DAG node 422C, local persistent storage 430C anda proxy 412C. In the depicted embodiment, DAG nodes 422 (and/or proxies412) may each comprise one or more threads of execution, such as a setof one or more processes. The local persistent storage devices 430 maybe used to store local replicas of application state information alongreplication path 491 (and/or DAG configuration-delta message contentsreceived at the DAG nodes 422 of the replication path 491) in thedepicted embodiment.

The DCM of the DAG depicted in the embodiment of FIG. 4 itself comprisesa plurality of nodes distributed across multiple availabilitycontainers. As shown, a consensus-based DCM cluster 490 may be used,comprising DCM node 472A with DCM storage 475A located in availabilitycontainer 466A, and DCM node 472B with DCM storage 475B located inavailability container 466B. The depicted DCM may thus be consideredfault-tolerant, at least with respect to failures that do not crossavailability container boundaries. The nodes of such a fault-tolerantDCM may be referred to herein as “configuration nodes”, e.g., incontrast to the member nodes of the DAG being managed by the DCM.Changes to the DAG configuration (including, for example, node removals,additions or role changes) may be approved using a consensus-basedprotocol among the DCM nodes 472, and representations of the DAGconfiguration may have to be stored in persistent storage by a pluralityof DCM nodes before the corresponding configuration-delta messages aretransmitted to the DAG nodes 422. The number of availability containersused for the DCM and/or for a given replication DAG may vary indifferent embodiments and for different applications, depending forexample on the availability requirements or data durability requirementsof the applications. In some embodiments, replication DAGs may be usedto manage the configuration of resources of other services implementedat a provider network. For example, changes to the state of computeinstances (virtual machines) or instance hosts (physical hosts) used bya virtualized computing service may be managed using a replication DAGin one embodiment.

FIG. 5 illustrates an example configuration in which nodes of aplurality of replication DAGs may be implemented at a single host in amulti-tenant fashion, according to at least some embodiments. As shown,nodes of three replication DAGs 555A, 555B and 555C are distributedamong four DAG node hosts 510A, 510B, 510C and 510D. In general, thenode hosts may differ in their resource capacities—e.g., the computing,storage, networking and/or memory resources of one host may differ fromthose of other hosts. For example, node host 510B has two storagedevices 530B and 530C that can be used for DAG information, node host510D has two storage devices 530E and 530F, while node hosts 510A and510C have one storage device (530A and 530D respectively).

Host 510A comprises an acceptor node 522A of DAG 555A, and anintermediate node 522N of DAG 555C. Host 510B comprises an intermediatenode 522B of DAG 555A, a committer node 522K of DAG 555B, and anintermediate node 522O of DAG 555C. Committer node 522C of DAG 555A andcommitter node 522P of DAG 555C may be implemented at host 510C.Finally, standby node 522C of DAG 555A, acceptor node 522J of DAG 555B,and acceptor node 522M of DAG 555C may be instantiated at host 510D.Thus, in general, a given host may be used for nodes of N differentDAGs, and each DAG may utilize M different hosts, where M and N may beconfigurable parameters in at least some embodiments. Nodes of severalDAGs established on behalf of respective application owners may beimplemented on the same host in a multi-tenant fashion in at least someembodiments: e.g., it may not be apparent to a particular applicationowner that the resources being utilized for state management of theirapplication are also being used for managing the state of otherapplications. In some provider network environments, a placement servicemay be implemented that selects the specific hosts to be used for agiven node of a given application's replication DAG. Node hosts may beselected on the basis of various combinations of factors in differentembodiments, such as the performance requirements of the applicationwhose state is being managed, the available resource capacity atcandidate hosts, load balancing needs, pricing considerations, and soon. In at least some implementations, instantiating multiple DAG nodesper host may help to increase the overall resource utilization levels atthe hosts relative to the utilization levels that could be achieved ifonly a single DAG node were instantiated. For example, especially inembodiments in which a significant portion of the logic used for a DAGnode is single-threaded, more of the processor cores of a multi-corehost could be used in parallel in the multi-tenant scenario than in asingle-tenant scenario, thereby increasing average CPU utilization ofthe host.

Methods for Implementing Dynamic DAG-Based State Replication

As discussed above, a given node of a replication DAG may be granted oneof a number of roles (e.g., acceptor, intermediate, committer, orstandby) in some embodiments at a given point in time. FIG. 6 is a flowdiagram illustrating aspects of operations that may be performed at anacceptor node of a replication DAG in response to receiving a statetransition request (STR), according to at least some embodiments. Asshown in element 601, the acceptor node may receive a message comprisingan STR for an application, e.g., from a client of a state replicationservice. The STR may comprise various elements in different embodiments,depending in part on the nature of the application. For example, in someembodiments as described below in greater detail, the DAG may be usedfor optimistic concurrency control for transactions directed at one ormore data stores, and the STR may include data such as read sets andwrite sets that can be used to detect conflicts withpreviously-committed transactions. Each application whose statetransitions are managed using a replication DAG may have its own set ofacceptance criteria for requested state transitions, and at least insome cases the contents of the STR may be used to decide whether thetransition should be accepted or rejected. In some implementations,operational conditions may also or instead be used foraccepting/rejecting requested state transitions—e.g., if the workloadlevel at the acceptor node or at other nodes of the DAG is at or above athreshold, the state transition may be rejected. If the transition meetsthe acceptance criteria (as detected in element 604), a new approvalsequence number may be generated for the accepted STR (element 607),e.g., by incrementing a counter value or by obtaining some othermonotonically increasing logical timestamp value. A record indicatingthat the transition was approved may be stored in local storage,together with the sequence number (element 610). For some applications,transition requests may include a data set (such as a write payload) tobe replicated, the acceptor node may store the data set in local storageas well. In one implementation the acceptor node may comprise one ormore processes running at a particular host of a provider network, andthe a record of the transition's approval, the sequence number and thetransition's data set may all be stored at a persistent disk-basedstorage device of the particular host. In some embodiments, thetransition's data, an indication that the transition was approved, andthe sequence number may all be combined into a single object stored atlocal storage, such as a log entry inserted into (or appended to) a log.In other embodiments, the transition's data set may be stored separatelyfrom the records indicating approval of the transition.

After the record of the state transition is safely stored, a statetransition message indicating the approval may be transmitted to aneighbor node along a replication path of the DAG (element 613) towardsa committer node. In some cases, depending on the topology of the DAG,multiple such messages may be sent, one to each neighbor node along thereplication path. As described earlier, each node of the DAG may haveits own view of the DAG configuration, which may not necessarilycoincide with the views of the other nodes at a given point in time. Theacceptor node may direct its approved state transition messages to theneighbor node(s) indicated in its current view of the DAG'sconfiguration in the depicted embodiment, even if that current viewhappens to be obsolete or incorrect from the perspective of the DCM ofthe DAG (or from the perspective of one or more other DAG nodes). Afterthe message(s) are sent, the state transition request's processing maybe deemed complete at the acceptor node (element 619). If the requestedtransition does not meet the acceptance criteria of the application (asalso detected in element 604), the transition may be rejected (element616). In some implementations, a notification or response indicating therejection may be provided to the requester.

FIG. 7 is a flow diagram illustrating aspects of operations that may beperformed at an intermediate node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments. After such a message STM1 is received (element 701),e.g., from an acceptor node or from another intermediate node, in someembodiments the intermediate node may determine whether state transitionmessages with lower sequence numbers are missing (e.g., if STM1 has asequence number of SN1, whether one or more STMs with smaller sequencenumbers than SN1 have not yet been received). If evidence of suchmissing state transition messages is found (element 704), theintermediate node may optionally submit a retransmit request for themissing STM(s) to immediate predecessor nodes along currently-knownreplication paths (element 707) in the depicted embodiment. In someimplementations, the intermediate node may wait to receive responses toits retransmit request before storing a record of the approved statetransition corresponding to STM1 in local storage. The approve recordfor STM1 may be stored, e.g., together with the approval sequence numberand any data set (such as a write payload) associated with thetransition (element 710). A state transition message (which may besimilar in content to the message that was received, or identical incontent to the message that was received) may then be sent to eachneighbor node on the currently-known replication path(s) towards acommitter node (element 713). In some implementations in which a statetransition's approval history is included within state transitionmessages, the intermediate node may add its (the intermediate node's)identifier to the list of approvers indicated in the outgoing statetransition message.

In some embodiments, instead of checking for missing sequence numbersbefore saving the approval record for STM1 in local storage, a differentapproach may be taken. For example, the intermediate node may check formissing sequence numbers after storing the approval record in localstorage and/or after transmitting a corresponding STM towards thecommitter node.

In one implementation, a networking protocol such as TCP (theTransmission Control Protocol) that guarantees in-order delivery ofmessages within a given connection may be used in combination with apull model for receiving STMs at non-acceptor nodes. In such animplementation, as long as an intermediate node, committer node orstandby node maintains a network connection with its immediatepredecessor along a replication path, the networking protocol may berelied upon to ensure that no messages are lost. If, at a given DAG nodeN1, the connection to the immediate predecessor node P1 is lost in suchan implementation, N1 may be responsible for establishing a newconnection to P1 (or to a different predecessor node if aconfiguration-delta message has been received indicating that P1 is nolonger part of the DAG), and requesting P1 to send any STMs withsequence numbers higher than the previously highest-received sequencenumber.

FIG. 8 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of a replication DAG in response toreceiving an approved state transition message, according to at leastsome embodiments. Upon receiving an approved state transition message(element 801), e.g., from an intermediate node or from an acceptor node,the committer node may determine whether the state transition meets theapplication's commit criteria. In some embodiments, the committer nodemay be able to determine, from the contents of the STM (such as anapproval history field), the number of replicas of application staterecords that have been saved thus far, and the transition may be deemedcommittable if the number of replicas exceeds a threshold. The replicacount thresholds may differ based on the application; for example, asingle replica at the acceptor node may be sufficient for someapplications. In other embodiments, the committer node may also have toconsider other factors before committing the transition, such as whetherthe committer node has already received all the STMs with lower sequencenumbers than the current STM's sequence number. In one embodiment, forexample, the committer node may have to wait until it receives andprocesses all such prior STMs before committing the current transition.

If the commit criteria (which may differ from application toapplication) are met (as detected in element 804), the committer nodemay store a commit record within its collection of application staterecords in local storage (element 807), e.g., together with the sequencenumber and the transition's data set (if any). In some implementations,the commit criteria may default to the acceptance criteria that havealready been verified at the acceptor node—that is, once the statetransition has been approved at an acceptor node, the committer node maycommit the state transition indicated in a received STM without havingto verify any additional conditions. In some embodiments, a copy of theapproval sequence number indicated in the STM may be stored as thecommit sequence number. Since some approved transitions may not getcommitted, in at least one embodiment a different set of sequencenumbers may be used for commits than is used for approvals (e.g., sothat the sequence of commit sequence numbers does not have any gaps). Ifstandby nodes are configured for the DAG, post-commit STMs may bedirected to one or more such standby nodes from the committer node. Inat least some embodiments, after the transition is committed, anotification of the commit may be provided to one or more other nodes ofthe DAG (element 810), e.g., to enable the other nodes to update theirapplication state information and/or for transmitting a response to thestate transition's requesting client indicating that the transition hasbeen committed.

In some embodiments in which missing STMs were not handled as part ofthe processing related to commit criteria, the committer node may takesimilar actions as were indicated in FIG. 7 with respect to missingSTMs. Thus, for example, if the committer node determines that one ormore STMs are missing (with lower sequence numbers than the sequencenumber of the received STM) (element 813), a retransmit request for themissing STMs may be sent to the immediate predecessor node(s) (element816) to complete processing of the received STM (element 822). If thecommit criteria were not met, the committer node may abort the statetransition (element 819). In some embodiments, an abort notification maybe sent to one or more other nodes of the DAG, and/or to the client thatrequested the state transition. In some implementations, as mentionedabove, if a state transition has been approved at an acceptor node, thereplication DAG may be responsible for (eventually) committing the statetransition even if one or more nodes of the replication pathway(including the acceptor node itself) fail. Aborting a state transitionmay require a relatively heavyweight change in some suchimplementations, such as the removal of approval records of thetransition from other DAG nodes (or the actual removal from the DAG ofthe nodes at which approval records happen to be stored). As describedbelow in further detail with respect to FIG. 11 a FIG. 14, a preemptivecoordinated DAG suspension technique may be used in some embodiments toavoid scenarios in which STMs reach committer nodes without thecorresponding state transition information having been replicated at adesired number of DAG nodes.

FIG. 9 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager (DCM) of a replication DAG,according to at least some embodiments. As shown in element 901, anevent that can potentially trigger a configuration change at a DAG maybe detected by the configuration manager. Such an event may includereceiving a message such as “node failure detected” (e.g., from a DAGnode, or from a health management component of a provider network) or“available for service” (e.g., from a DAG node that has restarted aftera failure). In some embodiments the configuration manager itself may beresponsible for monitoring the health status of various DAG nodes, andthe triggering event may be a detection by the configuration managerthat one of the nodes has not responded in a timely fashion to somenumber of heartbeat messages or other health checks. In at least someembodiments, the DAG nodes may be responsible for reporting any apparentnode failures (e.g., when a connection is unexpectedly dropped, or whenno message is received from a neighbor node for a time period greaterthan a threshold) to the DCM. A DAG node may also be responsible fornotifying the DCM of impending changes (such as when the node isscheduled to go offline for maintenance) that may lead to DAGconfiguration changes in some embodiments. The DCM may determine whetherthe indicated configuration change (e.g., a removal of a failed node, orthe joining of a new node) is to be made effective (element 904) in thedepicted embodiment, e.g., based on a consensus protocol that may beimplemented among a plurality of nodes of a DCM cluster. For example, insome implementations, a determination by one DCM node that a DAG nodehas failed may have to be confirmed at one or more other nodes of thecluster (e.g., by reviewing heartbeat responses received from the DAGnode at other DCM nodes) before the node is removed from theconfiguration. In other implementations, the decision as to whether toapply a possible configuration change may be performed without utilizinga consensus-based protocol. A sequence number or logical timestampassociated with the DAG configuration change may be determined orgenerated in some embodiments, e.g., for inclusion inconfiguration-delta messages sent to other nodes of the DAG so that theconfiguration changes can be processed in the correct order at the DAGnodes.

Independently of how the configuration change is approved, in someembodiments a representation of the configuration change may have to bereplicated at multiple storage locations of the DCM before the change isconsidered complete (element 907). Saving information about theconfiguration change in multiple locations may be an important aspect ofthe DCM's functionality in embodiments in which the DCM is to serve asthe authoritative source of DAG configuration information. In at leastsome implementations, only the change to the configuration (rather than,for example, the entire configuration) may be replicated. After theconfiguration change information has been saved, a set of DAG nodes towhich corresponding configuration-delta messages (indicating thejust-implemented change to the configuration, not necessarily the wholeconfiguration of the DAG) are to be sent from the DCM may be identified(element 910). In some embodiments, all the DAG members (potentiallyincluding a node that is being removed from the DAG as part of theconfiguration change indicated in the configuration-delta message) maybe selected as destinations for the configuration-delta messages. In oneembodiment, only the nodes that are assumed to be current DAG membersmay be selected, e.g., the configuration-delta message may not be sentto a node if it is being removed or is known to have failed. In otherembodiments, some subset of the members may be selected as destinations,and that subset may be responsible for propagating the configurationchanges to the remaining nodes. In embodiments in which a subset ofmembers are selected as destinations, the DCM may have to keep track ofwhich changes have been propagated to which members at any given time.After the destination set of DAG nodes have been identified, respectiveconfiguration-delta messages may be sent to them asynchronously withrespect to each other, and without requesting any pause in statetransition message processing or state transition request processing(element 913). In at least some embodiments, the configuration-deltamessages may include the configuration sequence number associated withthe configuration change. In some implementations, a compositeconfiguration-delta message may indicate two or more changes (e.g., aremoval of a failed node and a joining of a replacement node).

FIG. 10 is a flow diagram illustrating aspects of operations that may beperformed at a member node of a replication DAG in response to receivinga configuration-delta message from a configuration manager, according toat least some embodiments. Upon receiving such a configuration-deltamessage comprising a configuration change sequence number from the DCM(element 1001), the recipient DAG node may determine whether it hasmissed any prior configuration-delta messages in the depictedembodiment, e.g., by comparing the newly-received sequence number withthe highest sequence number received previously. If the recipientdetermines that one or more configuration-delta messages have not yetbeen received (element 1004), it may send a configuration refreshrequest to the DCM (element 1007). Such a refresh request may result inthe DCM re-sending the missed configuration-delta message or messages,for example, or in sending a different type of message in which theentire current configuration of the DAG is indicated.

If missing configuration-delta messages are not detected (also inoperations corresponding to element 1004), the recipient node may storethe received configuration change information in a configuration changerepository in local storage. The accumulated messages in the repositorymay be used to update the recipient's view of the DAG configuration(element 1010). Updating the local view of the DAG configuration mayinclude, for example, determining one or more DAG nodes and/or edges ofthe replication pathway or pathways to be used for future outgoing andincoming state transition messages. As mentioned earlier, because of theasynchronous nature of message delivery and because different parts of anetwork may experience different delays, the sequence in whichconfiguration-delta messages are obtained at one DAG node may differfrom the sequence in which the same set of configuration-delta messagesare received at another node. Accordingly, the replication pathwaysidentified at two different nodes at a given point in time may differfrom each other. In the depicted embodiment, the recipient node may takefurther actions if either its immediate predecessor node on areplication path has changed, or if its immediate successor has changed.If neither the immediate successor nor the immediate predecessor nodechanges, the processing of the configuration-delta message may end afterthe configuration change information is stored at local storage of therecipient node (element 1027) in some embodiments.

An example of a scenario in which an immediate predecessor node ischanged with respect to a node C of a DAG is the change of a portion ofa replication path from A-to-B-to-C to A-to-C. If the updatedconfiguration involves a change to an immediate predecessor node of therecipient, and no messages have yet been received directly from the newimmediate predecessor node (as detected in element 1013), the recipientnode (node C in the current example) may establish a connection to thenew immediate predecessor (node A in the current example). In addition,in at least some embodiments, the recipient node (e.g., node C) may alsosend a request to the new immediate predecessor (e.g., node A) forretransmission of STMs with sequence numbers higher than the mostrecently-received sequence number at the recipient node (element 1017).If node C has a successor node, it may continue to transmit any pendingstate transition messages to such a successor node while node C waits toreceive the requested retransmissions from node A.

If the configuration-delta message indicates that the immediatesuccessor node of the recipient has changed, (e.g., when mode A receivesthe same example configuration-delta message discussed above, indicatingthat node B has left the DAG), and no message has yet been received fromthe new immediate successor node (element 1021), the recipient node mayestablish a connection to the new successor node. In the above example,node A may establish a connection to node C, its new immediatesuccessor. State transition messages may subsequently be transferred tothe new immediate successor (element 1024).

Coordinated Suspension of Replication DAG Nodes

For provider network operators, large scale failure events that cancause near-simultaneous outages of a large number of applicationspresent a significant challenge. Customers whose applications areaffected by sustained outages may lose faith in the ability of theprovider networks to provide the levels of service needed for criticalapplications. Although the probability of large scale failure events canbe lowered by intelligent infrastructure design and by implementingapplication architectures that can take advantage of high-availabilityfeatures of the infrastructure, it may be impossible to eliminate largescale failures entirely. Techniques that can allow distributedapplications to recover more quickly and cleanly from failures thataffect multiple resources may therefore be developed in at least someembodiments. In some environments in which replication DAGs of the typedescribed above are employed for distributed application statemanagement, a coordinated suspension protocol may be used to supportmore effective and efficient recovery from distributed failures. In oneembodiment, for example, in response to a detection of a failurescenario, some number of nodes of a DAG may be directed by theconfiguration manager to stop performing their normal application statetransition processing operations (e.g., receiving state transitionrequest messages, storing local copies of application state information,and transmitting state transition request messages along theirreplication pathway(s)). After suspending their operations, the nodesmay synchronize their local application state records with other DAGnodes in at least some embodiments, perform a clean shutdown andrestart. After a node restarts, it may report back to the configurationmanager that it is available for resumption of service, and awaitre-activation of the DAG by the configuration manager.

FIG. 11 a-11 h collectively illustrate an example sequence of operationsthat may be performed at a replication DAG during such a coordinatedsuspension procedure, according to at least some embodiments. Each nodein the illustrated DAG may store a respective set of commit records, inwhich each commit record includes (or indicates, e.g., via a pointer) acorresponding commit sequence number (CSN). From the perspective of thenode, the local commit record set may thus represent the state of anapplication being managed using the DAG. Records of approved (but notyet committed) state transitions may also be kept at some or all of thenodes, as described earlier. It is noted that although the coordinatedsuspension technique is described herein in the context of dynamicreplication DAGs in which the DCM transmits configuration-delta messagesas described above to keep the DAG nodes updated regarding DAGconfiguration changes, a similar approach may be employed for otherstate replication techniques in some embodiments. For example, thecoordinated suspension technique may also be used in an environment inwhich configuration changes to a group of replication nodes areimplemented using a stop-the-world reconfiguration interval during whichall the nodes are updated in a synchronized fashion, such that thereplication group becomes operational only after all the nodes have beenmade aware of the new configuration. Thus, dynamic replication DAGs mayrepresent just one example of multi-node state replication groups (SRGs)at which the coordinated suspension technique may be implemented indifferent embodiments. At least some such SRGs may have their ownconfiguration managers analogous to the DCMs described earlier, and mayhave some nodes designated as committer nodes and other nodes designatedas non-committer nodes.

A replication DAG comprising five nodes 1102A, 1102B, 1102C, 1102D and1102E is shown in FIG. 11 a, together with a DCM 1180. In the depictedexample, committer node 1102E comprises a suspension trigger detector1106 which determines that a coordinated suspension procedure should beinitiated for the DAG. A number of different types of causes may lead tothe initiation of the suspension procedure in different embodiments. Forexample, the suspension procedure may be initiated (a) because somethreshold number of nodes may have failed (such as failures at nodes1102B and 1102D, indicated by the “X” symbols), (b) because the rate atwhich configuration-delta messages are being received at the committernode (or at some other node) exceeds a threshold, (c) because the rateat which network packets or connections are being dropped at some DAGnode or the DCM exceeds a threshold, and so on. The committer node 1102Ein the depicted embodiment sends a DAG suspension request 1150comprising the highest sequence number among the sequence numbersrepresented in the committer node's commit record set. This highestsequence number may be referred to as the highest committed sequencenumber (HCSN) 1108 herein, and may be used as a reference forsynchronizing commit record sets among the DAG nodes during one of thesteps of the suspension procedure as described below. In someembodiments, the initial determination that a suspension should beinitiated may be made at one of the non-committer nodes, or at the DCM1180 itself, and a particular commit sequence number (ideally but notnecessarily the HCSN) may be chosen as the target sequence number up towhich the nodes should update their commit record sets.

In response to receiving the suspension request, the DCM 1180 may savethe HCSN in persistent storage 1175, as shown in FIG. 11 b. The DCM maythen send respective suspend commands 1152 to at least a subset of theDAG nodes, such as commands 1152A and 1152B to nodes 1102A and 1102Crespectively in the depicted example scenario. In some embodiments, theDCM 1180 may send suspend commands to all the DAG nodes that are membersof the DAG according to the latest DAG configuration saved at the DCM(including the nodes that may have failed, such as 1102B and 1102D). Thesuspend commands may include the HCSN 1108.

Upon receiving a suspend command, a DAG node may stop processing statetransition requests/messages, and may instead begin a process to verifythat its commit record set includes all the commit records up to andincluding the commit record corresponding to the HSCN. It may be thecase, for example, that node 1102A and node 1102C may not yet have beennotified by the committer node 1102E regarding one or more committedstate transitions with sequence numbers less than or equal to the HCSN.In such a scenario, as shown in FIG. 11 c, node 1102A may send a commitrecords sync request 1172B to committer node 1102E (as indicated by thearrow labeled “1 a”) and node 1102C may send a similar commit recordssync request 1172B to node 1102E (as indicated by the arrow labeled “1b”). The commit records sync requests 1172 may respectively include anindication of which commit records are missing at the nodes from whichthe requests are sent—e.g., node 1102A may indicate that it already hascommit records with sequence numbers up to SN1, while node 1102C mayindicate that it is missing commit records with sequence numbers SN2,SN3, and SN4. The missing commit records 1174A and 1174B may then besent to the nodes 1102A and 1102C respectively by the committer node, asindicated by the arrows labeled “2 a” and “2 b”. Nodes 1102A and 1102Cmay then send respective synchronization confirmations 1176A and 1176Bto the DCM 1180, as indicated by the arrows labeled “3 a” and “3 b”. TheDCM 1180 may add nodes 1102A and 1102C to a list of up-to-date nodes1133 (i.e., nodes that have updated their commit record sets to matchthe commit record set of the committer node 1102E) maintained at theDCM's persistent storage 1175, as indicated by the arrow labeled “4”.

As shown in FIG. 11 d, the nodes of the DAG may terminate execution andrestart themselves in the depicted embodiment. The failed nodes 1102Band 1102D may restart as part of recovery from their failures, forexample. As part of the coordinated suspension procedure, nodes 1102Aand 1102C may save their commit record sets (and/or additional metadatapertaining to the operations of the nodes) in local storage after theircommit record sets have been synchronized with that of the committernode, and then initiate a controlled restart. Node 1102E may wait forsome time interval after it has sent the suspension request 1150(allowing the committer node to respond to at least some sync requests1172), save any state metadata to local storage, and then initiate itsown controlled restart as part of the suspension procedure in thedepicted embodiment.

After the DAG nodes 1102A-1102E come back online, they may each send arespective “available for service” message to the DCM 1180 in someembodiments, as shown in FIG. 11 e, and await re-activation instructionsto resume their application state transition processing operations. TheDCM may be able to tell (using its up-to-date nodes list 1133) that thecommit record sets of nodes 1102B and 1102D may not be up-to-date, andmay accordingly send respective synchronization commands 1194 to nodes1102B and 1102D, as shown in FIG. 11 f. In at least some implementationsthe synchronization commands may indicate the HCSN 1108. In response tothe synchronization commands 1194, nodes 1102B and 1102D may each sendtheir own commit records sync requests 1172C and 1172D to nodes that areknown to be up-to-date, indicating which commit records are missing intheir respective commit record sets. For example, node 1102B may sendits sync request 1172C to node 1102A, while node 1102D may send its syncrequest to node 1102E. In some embodiments, the DCM may specify thedestination nodes to which the commit records sync requests should besent. In one embodiment, all the non-committer DAG nodes may have tosynchronize their commit record sets with the committer node. Nodes1102B and 1102D may receive their missing commit records 1174C and 1174Drespectively, so that eventually all the nodes have synchronized theircommit record sets up to the HCSN. In some implementations, nodes 1102Band 1102D may send a confirmation to the DCM 1180 indicating that theircommit record sets have been updated/synchronized. In at least oneembodiment, the DCM may play a somewhat more passive role with respectto those nodes that are not in its up-to-date nodes list than describedabove with respect to FIG. 11 f. In such an embodiment, when a failednode (such as 1102B or 1102D) comes back online, it sends a message tothe DCM to determine whether the newly-online node is missing any commitrecords. The DCM may inform the node (e.g., by simply indicating theHCSN) that commit records with sequence numbers up to the HCSN arerequired for the node to become up-to-date. The node may then beresponsible for bringing itself up-to-date and reporting back to the DCMonce it has synchronized its commit records up to the HCSN. Thus, insuch an embodiment, the DCM may not necessarily send a synchronizationcommand 1194; instead, the newly-online nodes may take the initiative tosynchronize their commit record sets.

After confirming that at least a threshold number of the nodes haveupdated commit record sets, the DCM 1180 may determine the configurationof the post-restart DAG. In some cases, the same configuration that wasin use prior to the suspension may be re-used, while in otherembodiments a different configuration may be selected. For example, itmay be the case that the DAG is required to have a minimum of fournodes, so only four of the nodes 1102A-1102E may be selected initially.As shown in FIG. 11 g, the DCM 1180 may send respective re-activationmessages to the selected set of nodes (all five nodes in the depictedexample), indicating the current configuration of the DAG. The DAG nodesmay then resume normal operations, as indicated by FIG. 11 h. In someembodiments, at least some of the DAG nodes that did not fail (e.g.,1102A, 1102C and 1102E) may not necessarily restart themselves. Instead,after synchronizing their commit record sets, one or more of such nodesmay simply defer further state transition processing until they receivea re-activation command from the DCM in such embodiments.

FIG. 12 is a flow diagram illustrating aspects of operations that may beperformed at a committer node of an SRG such as a replication DAG duringa coordinated suspension procedure, according to at least someembodiments. As shown in element 1201, the committer node may determinethat a triggering criterion for a coordinated suspension of the SRG hasbeen met. A variety of different triggering conditions may lead to acoordinated suspension, including, for example, a detection by thecommitter node that the number of SRG nodes that remain responsive hasfallen below a threshold, or that the rate at which the SRG'sconfiguration changes are occurring exceeds a threshold. In some casesresource workload levels or error rates may trigger the suspension—e.g.,if the rate at which network packets are dropped exceeds a threshold, orif connections are being unexpectedly terminated at or above a maximumacceptable rate. In one embodiment, a non-committer node of the SRG, ora configuration manager such as the DCM, may initially detect a problemthat should lead to a controlled suspension, and may inform thecommitter node about the problem.

After determining that controlled suspension is to be initiated, thecommitter node may pause or stop its normal processing/replication ofstate transition messages, and save any outstanding as-yet-unsavedcommit records to local storage (element 1204) in the depictedembodiment. The committer node may then transmit a suspension request,including an indication of the HCSN (the highest-committed sequencenumber among the sequence numbers of transitions for which commitrecords have been stored by the committer node), to the SRG'sconfiguration manager (e.g., the DCM in the case of a replication DAG)(element 1207). The HCSN may serve as the target commit sequence numberup to which currently active nodes of the SRG are to synchronize theircommit record sets.

In at least some embodiments, after it sends the suspension request, thecommitter node may receive some number of commit record sync requestsfrom other SRG nodes (e.g., nodes that have determined that they do nothave a full set of commit records with sequence numbers up to the HCSN)(element 1210). In the depicted embodiment, the committer node respondto any such sync requests that are received during a configurable timewindow. The committer node may then optionally perform a clean shutdownand restart and send an available-for-service message to theconfiguration manager of the SRG (element 1213). In some embodiments,the clean shutdown and restart may be omitted, and the committer nodemay simply send an available-for service message, or the committer nodemay simply defer further state transition-related processing untilre-activation instructions are received from the configuration manager.Eventually, the committer node may receive a re-activation message fromthe configuration manager, indicating the current post-suspensionconfiguration of the DAG, and the committer node may then resume statetransition related processing (element 1216) as per the indicatedconfiguration. In some embodiments, it may be the case that in the new,post-suspension configuration, the committer node is no longer grantedthe role of committer; instead, it may be configured as an acceptornode, an intermediary node or a standby node, for example.

FIG. 13 is a flow diagram illustrating aspects of operations that may beperformed at a non-committer node of a state replication group such as areplication DAG during a coordinated suspension procedure, according toat least some embodiments. During normal operations, the non-committernode may store commit records in local storage at some point after thecorresponding transitions have been committed; as a result, the localcommit record set of the non-committer node may not necessarily be ascurrent as that of the committer node. As shown in element 1301, thenon-committer node may receive a suspend command from the configurationmanager, indicating an HCSN as the target sequence number to which thenon-committer node should synchronize its local commit record set.

Upon receiving the suspend command, the non-committer node may pause orstop processing new state transition messages. If some commit recordswith lower sequence numbers than the HCSN are missing from the localcommit record set, the non-committer node may send a commit record syncrequest for the missing records to the committer node (or to a differentnode indicated by the configuration manager as a source for missingcommit records) (element 1304). If its commit record set is alreadyup-to-date with respect to the HCSN, the non-committer node may not needto communicate with other nodes at this stage of the suspensionprocedure. After verifying that commit records with sequence numbers upto the HCSN are stored in local storage, the non-committer node may senda sync confirmation message to the configuration manager (element 1307)in the depicted embodiment. The non-committer node may then deferfurther application state transition processing until it is re-activatedby the configuration manager. Optionally, the non-committer node mayperform a clean shutdown and restart, and send an“available-for-service” message to the configuration manager afterrestarting (element 1310). In response to a re-activation message fromthe configuration manager, the non-committer node may update its view ofthe SRG configuration and resume application state transition processing(element 1313). In the post-suspension configuration, a different rolemay be granted to the non-committer node by the configuration manager insome cases—e.g., the non-committer node's role may be changed to acommitter node.

FIG. 14 is a flow diagram illustrating aspects of operations that may beperformed at a configuration manager of a state replication group suchas a replication DAG during a coordinated suspension procedure,according to at least some embodiments. As shown in element 1401, theconfiguration manager may receive a suspension request from a committernode of the SRG, indicating a highest-committed sequence number (HCSN)from among the sequence numbers of transitions whose commit records arestored at the committer node. In some embodiments, a consensus protocolmay be employed among the various nodes of the configuration managerbefore the decision to suspend the SRG operations is made final. Theconfiguration manager may store the HCSN in persistent storage (element1404) (e.g., at respective storage devices at several nodes of aconfiguration manager cluster), and send suspend commands indicating theHCSN to one or more other nodes of the SRG (element 1407). In someembodiments, the suspend commands may be sent to all the known membersof the SRG, including nodes that are assumed to have failed. Therecipient nodes of the SRG may each verify that their local commitrecord sets contain commit records corresponding to the HCSN (which mayin some cases require the recipient nodes to obtain missing commitrecords from the committer node as described above). After verifyingthat its commit record set is current with respect to the HCSN, arecipient of the suspend command may send the configuration manager async confirmation indicating that its commit record set is nowup-to-date. Accordingly, upon receiving such a confirmation from an SRGnode, the configuration manager may add that node to a list ofup-to-date nodes (element 1410).

In some embodiments, the configuration manager may wait to receiverespective messages from the SRG nodes indicating that they areavailable for service. Upon receiving such a message from a node (e.g.,after the node has completed a clean shutdown and restart, or after thenode has come back online after a failure), the configuration managermay determine whether the node is in the up-to-date nodes list or not.If the node from which the “available-for-service” indication isreceived is not known to be up-to-date with respect to commit records,the configuration manager may send indicate the HCSN to the node(element 1413), e.g., in an explicit synchronization command or inresponse to an implicit or explicit query from the node. Using the HCSNas the target sequence number up to which commit records are to beupdated, the node may then update its local commit record set bycommunicating with other nodes that are already up-to-date. In someembodiments, the configuration manager may include, in thesynchronization command, an indication of the source from which anout-of-date node should obtain missing commit records.

After the configuration manager has confirmed that a required minimumnumber of SRG nodes are (a) available for service and (b) up-to-datewith respect to application commit state, the configuration manager mayfinalize the initial post-suspension configuration of the SRG (element1416). The configuration manager may then send re-activation messagesindicating the configuration to the appropriate set of nodes that are inthe initial configuration (element 1419). In some embodiments, theinitial configuration information may be provided to the nodes as asequence of configuration-delta messages.

In at least some embodiments, the target sequence number selected forsynchronization (i.e., the sequence number up to which each of aplurality of nodes of the SRG is to update its local set of commitrecords) need not necessarily be the highest committed sequence number.For example, it may be the case that the highest committed sequencenumber at a committer node is SN1, and due to an urgent need to suspendthe SRG's operations as a result of a detection of a rapidly escalatinglarge-scale failure event, the SRG configuration manager may be willingto allow nodes to suspend their operations after updating their commitrecords to a smaller sequence number (SN1 −k). In some implementations,the nodes of the SRG may synchronize their commit records to some lowersequence number before suspending/restarting, and may synchronize to thehighest-committed sequence number after the suspension—e.g., after thenodes restart and send “available-for-service” messages to theconfiguration manager. As noted earlier, in some embodiments thesuspension procedures may be initiated by non-committer nodes, or by theconfiguration manager itself.

Log-Based Optimistic Concurrency Control for Multiple-Data-StoreTransactions

In some embodiments, replication DAGs of the type described above may beused to implement optimistic concurrency control techniques using alogging service that enables support for transactions involving multipleindependent data stores. FIG. 15 illustrates an example systemenvironment comprising a persistent change log supporting transactionsthat may include writes to a plurality of data stores, according to atleast some embodiments. System 1500 shows a persistent change log 1510that may be instantiated using a logging service. One or more datastores 1530, such as data store 1530A (e.g., a NoSQL or non-relationaldatabase) and data store 1530B (e.g., a relational database) may beregistered at the logging service for transaction management in thedepicted embodiment. The terms “concurrency control”, “transactionmanagement”, and “update management” may be used as synonyms herein withrespect to the functionality provided by the logging service.

Clients 1532 may submit registration requests indicating the set of datasources for which they wish to use log-based transaction management fora particular application in some embodiments, e.g., via anadministrative or control-plane programmatic interface presented bylogging service manager 1501. The persistent change log 1510 may beinstantiated in response to such a registration request in someembodiments. In general, a given persistent change log instance may becreated for managing transactions for one or more underlying datastores—that is, in at least some deployments log-based transactionmanagement may be used for a single data store rather than for multipledata stores concurrently. The term “data store”, as used herein, mayrefer to an instance of any of a wide variety of persistent or ephemeraldata repositories and/or data consumers. For example, some data storesmay comprise persistent non-relational databases that may notnecessarily provide native support for multi-item transactions, whileother data stores may comprise persistent relational databases that maynatively support multi-item transactions. In some embodiments, anetwork-accessible storage service of a provider network that enablesits users to store unstructured data objects of arbitrary size,accessible via a web-services interface, may be registered as one of thedata stores. Other types of data stores may comprise in-memorydatabases, instances of a distributed cache, network-accessible blockstorage services, file system services, or materialized views. Entitiesthat consume committed writes recorded by the logging service, e.g., toproduce new data artifacts, may represent another type of data store,and may be referred to generically as “data consumers” herein. Such datastores may, for example, include a pre-computed query results manager(PQRM) (as in the case of data store 1530C) responsible for generatingresults of specified queries on a specified set of data managed via thelogging service (where the specified set of data may include objectsstored at one or more different other data stores). In some embodiments,snapshot managers configured to generate point-in-time snapshots of someor all committed data managed via the logging service may representanother category of data stores. Such log snapshots may be stored for avariety of purposes in different embodiments, such as for backups or foroffline workload analysis. The term “data consumers” may be used hereinto refer to data stores such as PQRMs and snapshot managers. At leastsome of the data stores may have read interfaces 1531 that differ fromthose of others—e.g., data store (DS) read interface 1531A of data store1530A may comprise a different set of APIs, web-based interfaces,command-line tools or custom GUIs (graphical user interfaces) than DSread interface 1531B or pre-computed query interface 1531C in thedepicted embodiment.

In the depicted embodiment, logging service clients 1532 may constructtransaction requests locally, and then submit (or “offer”) thetransaction requests for approval and commit by the persistent changelog 1510. In one implementation, for example, a client-side library ofthe logging service may enable a client to initiate a candidatetransaction by issuing the logical equivalent of a “transaction-start”request. Within the candidate transaction, a client may perform somenumber of reads on a selected set of objects at data stores 1530,locally (e.g., in local memory) perform a proposed set of writesdirected at one or more data stores. The client may then submit thecandidate transaction by issuing the equivalent of a “transaction-end”request. The candidate transaction request 1516 may be received at aconflict detector 1505 associated with the persistent change log 1510via the log's write interface 1512 in the depicted embodiment. Ingeneral, in at least some embodiments, a given transaction request 1516may include one or more reads respectively from one or more data stores,and one or more proposed writes respectively directed to one or moredata stores, where the set of data stores that are read may or may notoverlap with the set of data stores being written.

The reads may be performed using the native DS read interfaces 1531 insome embodiments (although as described below, in some scenarios clientsmay also perform read-only operations via the persistent change log1510).

At least some of the writes indicated in a given transaction request maybe dependent on the results of one or more of the reads in someembodiments. For example, a requested transaction may involve readingone value V1 from a location L1 at a data store DS1, a second value V2from a second location L2 at a data store DS2, computing a functionF(V1, V2) and storing the result of the function at a location L3 atsome data store DS3. In some locking-based concurrency controlmechanisms, exclusive locks may have to be obtained on L1 and L2 toensure that the values V1 and V2 do not change before L3 is updated. Inthe optimistic concurrency control mechanism of the logging serviceillustrated in FIG. 15, no locks may have to be obtained. Instead, inthe depicted embodiment, the conflict detector 1505 may determine, basedat least in part on the contents of the transaction descriptor 1516 andon a set of committed transaction log records 1527 of persistent changelog 1510, whether the set of data items read in the requestedtransaction have been updated since they were read from their respectivedata stores. A sequence number based technique may be used to determinewhether such read-write conflicts exist in at least some embodiments, asdescribed below in further detail. If the conflict detector 1505determines that none of the data that was read during the transactionwas overwritten, the requested transaction may be accepted for commit,and such accepted-for-commit transactions 1514 may be submitted forreplication of corresponding log records at the persistent change log.The terms “approve” and “accept” may be used as synonyms herein withrespect to requested transactions that are not rejected. If some of theread data was updated since the corresponding reads occurred (or if aprobability that the data was updated is estimated by the conflictdetector to be greater than a threshold), the requested transaction 1516may instead be rejected or aborted in the depicted embodiment. This typeof approach to concurrency control may be deemed optimistic in thatdecisions as to whether to proceed with a set of writes of a transactionmay be made initially under the optimistic assumption that read-writeconflicts are unlikely. As a result, in scenarios in which read-writeconflicts are in fact infrequent, higher throughputs and lower responsetimes may be achieved than may be possible if more traditionallocking-based techniques are used.

In the case where a transaction is accepted for commit, contents of acommitted transaction log record may be replicated at some number ofnodes of a replication DAG associated with the persistent change log1510 (as described below in further detail with respect to FIG. 16) inthe depicted embodiment before the commit is considered successful. Ifthe requisite number of replicas is not created, the transaction may berejected or aborted in the depicted embodiment. The number of replicasrequired for a commit may vary for different applications or clients.Committed transaction log records may also be referred to herein as“commit records”. In some embodiments, the requesting client 1532 may benotified when the requested transaction is committed. In at least oneembodiment, the client 1532 may be informed when a transaction isrejected, so that, for example, a new transaction request may begenerated and submitted for the desired updates.

For each transaction that is committed, in at least some embodiments acommit sequence number (or some other identifier indicative of thecommitted state of the application) may be generated and stored (e.g.,as part of each of the replicas of the committed transaction log record)at the persistent change log 1532. Such a commit sequence number may,for example, be implemented as a counter or as a logical timestamp, asdiscussed above with respect to the sequence numbers used at replicationDAGs for state transitions. The commit sequence number may bedetermined, for example, by the conflict detector in some embodiments,or at a different component of the persistent change log (such as thecommitter node of the replication DAG being used) in other embodiments.In the depicted embodiment, after a given transaction is committed andits commit record is stored at the persistent change log, the writes ofthe transaction may be applied or propagated to one or more of the datastores 1530 to which they were directed (or, as in the case of the PQRM1530C, where the written data is to be consumed). In someimplementations, the writes may be pushed in an asynchronous fashion tothe targeted data stores 1530. Thus, in such implementations, there maybe some delay between the time at which the transaction is committed(i.e., when the required number of replicas of the commit record havebeen successfully stored) and the time at which the payload of aparticular write operation of the committed transaction reaches thecorresponding data store. In the embodiment shown in FIG. 15, respectiveasynchronous write appliers 1517 may be used to propagate some or all ofthe writes to relevant data stores. For example, write applier 1517A isconfigured to apply writes 1515A that are relevant to or data store1530A, write applier 1517B pushes writes relevant to data store 1530B,and write applier 1517C pushes writes that are to be consumed at datastore 1530C. In some implementations, the write appliers may comprisesubcomponents (e.g., threads or processes) of the persistent change log1510, while in other implementations, write appliers 1517 may beimplemented as entities external to the persistent change log. In someembodiments, a given write applier 1517 may be responsible forpropagating writes to more than one data store 1530, or a single datastore 1530 may receive writes from a plurality of write appliers 1517.In at least one implementation, a pull technique may be used topropagate written data to the data stores—e.g., one or more data stores1530 may submit requests for writes to the persistent change log 1510 orthe write appliers, instead of being provided written data at theinitiative of the write appliers. After the data written during atransaction is applied to the corresponding data stores, clients 1532may be able to read the updated data using the respective readinterfaces of the data stores. In some embodiments, at least one of thewrite appliers may be capable of performing synchronous writes (e.g.,either when explicitly directed to do so by the logging service, or forall the writes for which the applier is responsible). For example, aclient may wish to ensure that at least one write of a given transaction(such as a write directed to a “master” data store among the pluralityof data stores involved in the transaction) has been applied before theclient is informed that the transaction has been committed. The specificwrites to be performed synchronously may be indicated in the transactionrequest 1516 in some embodiments.

In some embodiments, as described below in further detail, a giventransaction request 1516 may include respective indicators of a read setof the transaction (i.e., information identifying the set of dataobjects read during the transaction), the write set of the transaction(i.e., information identifying the set of data objects that are to beupdated/written if the transaction is committed), the write payload(i.e., the set of data bytes that are to be stored for each write),and/or a conflict check delimiter (an indication of a subset of thecommitted transaction log records that should be examined toaccept/reject the transaction). Some or all of these constituentelements of a transaction request may be stored within the correspondingcommit record, together with the commit sequence number for thetransaction. In at least one embodiment, the persistent change log 1510may provide an identifier 1590 of the latest committed state of theapplication (such as the highest commit sequence number generated thusfar), e.g., in response to a query from a data store or a query from alogging service client. The write appliers may indicate the commitsequence numbers corresponding to the writes that they apply at the datastores in the depicted embodiment. Thus, at any given point in time, aclient 1532 may be able (e.g., by querying the data store) to determinethe commit sequence number corresponding to the most-recently-appliedwrite at a given data store 1530.

In at least some embodiments, during the generation of a transactionrequest (e.g., by a client library of the logging service), themost-recently-applied commit timestamps may be obtained from the datastores that are accessed during the transaction, and one or more of suchcommit sequence numbers may be indicated in the transaction request asthe conflict check delimiter. For example, consider a scenario in which,at the time that a particular client initiates a transaction thatincludes a read of a location L1 at a data store DS1, the commitsequence number corresponding to the most recently applied write at DS1is SN1. Assume further that in this example, the read set of thetransaction only comprises data of DS1. In such a scenario, SN1 may beincluded in the transaction request 1516. The conflict detector mayidentify commit records with sequence numbers greater than SN1 as theset of commit records to be examined for read-write conflicts for therequested transaction. If any of the write sets of the identified commitrecords overlaps with the read set of the requested transaction, thetransaction may be rejected/aborted; otherwise, the transaction may beapproved for commit in this example scenario.

In the depicted embodiment, the logging service may expose one or moreprogrammatic log read interfaces 1513 (e.g., APIs, web-pages,command-line utilities, GUIs, and the like) to enable clients 1532 toread log records directly. In other embodiments, such read APIs allowingdirect access to the change log 1510 may not be implemented. The abilityto directly access log records indicating specific transactions thathave been committed, and to determine the order in which they werecommitted, may enable new types of analyses to be performed in someembodiments than may be possible from accessing just the data storesdirectly (since at least some of the data stores may typically onlyallow readers to see the latest-applied versions of data objects, andnot the histories of data objects).

The optimistic concurrency control mechanism illustrated in FIG. 15 mayallow more complex types of atomic operations to be supported than mayhave been possible using the underlying data stores' concurrency controlmechanisms in at least some scenarios. For example, somehigh-performance non-relational data stores may only allow single-itemtransactions (i.e., writes may be permitted one at a time, but ifmultiple writes are submitted in a single batch update,atomicity/consistency guarantees may not be provided for the multiplewrites taken together). With the log-based approach described above, asingle transaction that encompasses writes to multiple locations of thenon-relational data store (and/or other data stores as well) may besupported with relative ease. A persistent change log 1510, togetherwith the associated conflict detector 1505, may be referred to as alog-based transaction manager herein. In some embodiments, the writeappliers 1517 may also be considered subcomponents of the transactionmanager.

As mentioned above, the persistent change log 1510 may be implementedusing the replication DAG described earlier in some embodiments. FIG. 16illustrates an example implementation of a persistent change log using areplication DAG 1640, according to at least some embodiments. In thedepicted embodiment, the application state transitions managed by theDAG correspond to transactions requested by log client 1660 as part ofan application that includes reads and writes directed to a set of oneor more data stores. The state of the application may be modeled as arespective set of transaction records 1672 stored in local storage atacceptor node 1610, intermediate node 1612, committer node 1614 andstandby node 1616, with a current replication path comprising nodes1610, 1612 and 1614. In some implementations, separate transactionrecords for approval (i.e., indicating that the requested transactionhas been approved for commit) and commit may be stored, while in otherembodiments, a single transaction record may be stored with a field thatindicates whether the transaction has been committed or not. A sequencenumber or logical timestamp may be stored as part of, or indicated by,at least some of the transaction records in the depicted embodiment.

The decision as to whether a requested transaction 1650 is to beapproved for commit may be made by a conflict detector implemented atthe acceptor node 1610 in the depicted embodiment, although in otherembodiments the conflict detector may be implemented outside thereplication DAG. A fault-tolerant log configuration manager 164 may sendconfiguration-delta messages asynchronously to the DAG nodes 1610, 1612,1614 and 1616, with each such message indicating a change to the DAGconfiguration rather than the entire configuration of the DAG, andwithout requiring the DAG nodes to pause processing the stream ofincoming transaction requests submitted by client 1660. Each DAG nodemay independently process or aggregate the configuration-delta messagesreceived to arrive at its respective view 1674 (e.g., view 1674A at node1610, view 1674B at node 1612, view 1674C at node 1614, and view 1674Dat node 1616) of the current DAG configuration. At least some of theviews 1674 may differ from those at other nodes at a given point intime; thus, under normal operating conditions, the different DAG nodesmay not need to synchronize their view of the DAG configuration witheach other. Messages 1652A and 1652B indicating approved (but not yetcommitted) transactions may be transmitted from acceptor node 1610 andintermediate node 1612 respectively along the replication pathway. Inthe depicted embodiment, committer node 1614 may transmit messages 1653indicating commits to the acceptor and intermediate nodes as well as tostandby node 1616. Asynchronous write appliers 1692, shown in theembodiment of FIG. 16 as entities outside the replication DAG, maypropagate writes from various committed transaction records to theappropriate data stores or data consumers. In other embodiments, thewrite appliers may be implemented within the replication DAG, e.g., asrespective processes running within the DAG nodes. In someimplementations, only a subset of the DAG nodes may be read by theappliers 1692 in order to propagate committed writes to theirdestination data sources or consumers. In other embodiments, as shown inFIG. 16, the appliers may read committed transaction records from any ofthe DAG nodes to push the contents of the write payloads as describedearlier.

Transaction Request Elements

FIG. 17 illustrates example component elements of a transaction requestdescriptor 1744 that may be submitted by a client 1732 of a loggingservice, according to at least some embodiments. As shown, transactiondescriptor 1744 may include conflict check delimiter 1702, read setdescriptor 1704, write set descriptor 1706, write payload(s) 1708, andoptional logical constraint descriptors 1710 in the depicted embodiment.In the example shown, logging service client 1732 comprises a clientlibrary 1756 which may be utilized to assemble the transaction requestdescriptor. In at least some embodiments, the client library mayautomatically record the read locations 1761A 1761B, and 1761Crespectively within data stores 1730A, 1730B and 1730C from which datais read during the transaction, and/or the write location 1771 (of datastore 1730C in the depicted example) to which data is written. In someimplementations, the client library 1756 may also obtain, from each ofthe data sources 1730, a corresponding commit sequence number (CSN) ofthe most recent transaction whose writes have been applied at the datastore most recently. In one embodiment, such CSNs may be retrievedbefore any of the reads of the transaction are issued to thecorresponding data stores, for example. In another embodiment, the CSNsmay be retrieved from a given data store 1730 just before the first readthat is directed to that data store within the current transaction isissued.

In the depicted embodiment, the conflict check delimiter 1702 may bederived from a function to which the most-recently-applied CSNs areprovided as input. For example, in one implementation, the minimumsequence number among the CSNs obtained from all the data stores readduring the transaction may be used. In another implementation, a vectoror array comprising the CSNs from each of the data stores may beincluded as the conflict check delimiter 1702 of the transaction requestdescriptor. The conflict check delimiter 1702 may also be referred toherein as a committed state identifier (CSI), as it represents acommitted state of one or more data stores upon which the requestedtransaction depends. In some embodiments, a selected hash function maybe applied to each of the read locations 1761A, 1761B or 1761C to obtaina set of hash values to be included in read descriptor 1704. Similarly,a selected hash function (either the same function as was used for theread descriptor, or a different function, depending on theimplementation) may be applied to the location of the write(s) of atransaction to generate the write set descriptor 1706. In otherembodiments, hashing may not be used; instead, for example, an un-hashedlocation identifier may be used for each of the read and write setentries. The write payload 1708 may include a representation of the datathat is to be written for each of the writes included in thetransaction. Optional logical constraints 1710 may include signaturesused for duplicate detection/elimination and/or for sequencing specifiedtransactions before or after other transactions, as described below infurther detail. Some or all of the contents of the transaction requestdescriptor 1744 may be stored as part of the transaction state records(e.g., approved transaction records and/or committed transactionrecords) replicated at the persistent change log 1510 in someembodiments.

It is noted that the read and write locations from which the readdescriptors and write descriptors are generated may represent differentstorage granularities, or even different types of logical entities, indifferent embodiments or for different data stores. For example, for adata store comprising a non-relational database in which a particulardata object is represented by a combination of container name (e.g., atable name), a user name (indicating the container's owner), and someset of keys (e.g., a hash key and a range key), a read set may beobtained as a function of the tuple (container-ID, user-ID, hash key,range key). For a relational database, a tuple (table-ID, user-ID,row-ID) or (table-ID, user-ID) may be used.

In various embodiments, the transaction manager may be responsible,using the contents of a transaction request and the persistent changelog, for identifying conflicts between the reads indicated in thetransaction request and the writes indicated in the log. For relativelysimple read operations, generating a hash value based on the locationthat was read, and comparing that read location's hash value with thehash values of writes indicated in the change log may suffice fordetecting conflicts. For more complex read requests in some embodiments,using location-based hash values may not always suffice. For example,consider a scenario in which a read request R1 comprises the query“select product names from table T1 that begin with the letter ‘G’”, andthe original result set was “Good-product1”. If, by the time that atransaction request whose write W1 is dependent on R1's results isexamined for acceptance, the product name “Great-product2” was insertedinto the table, this would mean that the result set of R1 would havechanged if R1 were re-run at the time the transaction acceptancedecision is made, even though the location of the “Good-product1” dataobject may not have been modified and may therefore not be indicated thewrite records of the log. To handle read-write conflicts with respect tosuch read queries, or for read queries involving ranges of values (e.g.,“select the set of product names of products with prices between $10 and$20”), in some embodiments logical or predicate-based read setdescriptors may be used. The location-based read set indicatorsdescribed above may thus be considered just one example category ofresult set change detection metadata that may be used in variousembodiments for read-write conflict detection.

Read-Write Conflict Detection

FIG. 18 illustrates an example of read-write conflict detection at alog-based transaction manager, according to at least some embodiments.In the depicted example, transaction commit records (CRs) 1852 stored atpersistent change log 1810 are shown arranged in order of increasingcommit sequence numbers from the top to the bottom of the log. Thelatest or most recently committed transaction is represented by CR1852F, with commit sequence number (CSN) 1804F and write set descriptor(WSD) 1805F. Each of CRs 1852A, 1852B, 1852C, 1852D and 1852E comprise acorresponding CSN 1804 (e.g., CSNs 1804A-1804E respectively) and acorresponding WSD 1805 (e.g., WSDs 1805A-1805E).

As shown, transaction request descriptor 1844 includes a conflict checkdelimiter (or committed state identifier) 1842, a read set descriptor1846 and a write set descriptor 1848. (The write payload of therequested transaction is not shown). The conflict detector of thelog-based transaction management system may be required to identify aset of CRs of log 1810 that are to be checked for conflicts with theread set of the requested transaction. The conflict check delimiter 1842indicates a lower-bound CSN that may be used by the conflict detector toidentify the starting CR of set 1809 to be examined for read-writeconflicts with the requested transaction in the depicted embodiment, asindicated by the arrow labeled “Match”. Set 1809 may include all the CRsstarting with the matching sequence number up to the most recentcommitted transaction (CR 1852F) in some embodiments. If any of thewrites indicated by the CR set 1809 overlap with any of the readsindicated in the transaction request 1844, such a read-write conflictmay lead to a rejection of the requested transaction. A variety ofmechanisms may be used to check whether such an overlap exists indifferent embodiments. In one embodiment, for example, one or morehashing-based computations or probes may be used to determine whether aread represented in the read set descriptor 1846 conflicts with a writeindicated in the CR set 1809, thereby avoiding a sequential scan of theCR set. In some implementations, a sequential scan of CR set 1809 may beused, e.g., if the number of records in the CR set is below a threshold.If none of the writes indicated in CR set 1809 overlap with any of thereads of the requested transaction, the transaction may be accepted,since none of the data that were read during the preparation of thetransaction request can have changed since they were read. In at leastone embodiment, a transaction request descriptor may also indicate anupper bound on the sequence numbers of transaction records to be checkedfor conflicts—e.g., the conflict check delimiter may indicate both astarting point and an ending point within the set of CS 1852.

Methods for Optimistic Log-Based Concurrency Control

FIG. 19 is a flow diagram illustrating aspects of control-planeoperations that may be performed at a logging service, according to atleast some embodiments. At least some of the administrative orconfiguration-related operations shown may be performed by a loggingservice manager 1501 such as that illustrated in FIG. 15, e.g., inresponse to invocations of one or more administrative programmaticinterfaces implemented at the logging service. As shown in element 1901,one or more data stores may be registered for transaction management viaa logging service that implements an optimistic concurrency controlmechanism, e.g., using the read-write conflict detection approachdescribed above. Transaction management for a variety of types of datastores with respective distinct read interfaces may be implemented usinga log-based approach in different embodiments, including for exampleinstances of relational databases, non-relational databases, in-memorydatabases, provider network-implemented storage services, distributedcache components, pre-computed query results managers, snapshotmanagers, and so on. In some embodiments, some or all of the underlyingdata stores managed using a given log instance may not support at leastsome of the ACID properties (atomicity, consistency, isolation anddurability) that are supported by some traditional relational databasesystems.

The logging service may identify a set of hosts to be used forreplication DAG nodes of a persistent change log to be implemented forthe registered data stores (element 1904), e.g., with the help of aprovisioning service implemented at a provider network. One or morehosts may also be identified for a configuration manager for thereplication DAG—for example, as described earlier, a cluster of nodesutilizing a consensus-based protocol for implementing DAG configurationchanges may be used in some implementations. Replication nodes and theconfiguration manager may be instantiated at the selected hosts. Othercomponents of the log-based transaction management mechanism, includingthe conflict detector, one or more write appliers and an optional readinterface manager for the persistent change log may be configured(element 1907). The read interface manager for the log may beresponsible in some embodiments for responding to read requestssubmitted directly to the log (instead of being submitted to the readinterfaces of the registered data stores). The write appliers may beinstantiated, in one example implementation as respective processes orthreads that subscribe to notifications when transactions are committedat the log. The conflict detector may comprise a module that utilizesthe read interface of the log in some embodiments. Configuration of theconflict manager may include, for example, establishing the order inwhich read-write conflicts are identified versus constraint checkingoperations corresponding to de-duplication or sequencing, the manner inwhich responses to clients are provided (e.g., whether and how clientsare informed regarding transaction rejections/commits), and so on. Insome embodiments, conflict detectors, write appliers and/or log readinterface managers may be implemented in a multi-tenant fashion—e.g., agiven conflict detector, write applier or read interface manager mayprovide its services to a plurality of clients for whom respective loginstances have been established.

After the various components of the persistent change log have beenconfigured, the flow of transaction requests from clients may be enabled(element 1910), e.g., by providing the appropriate network addressesand/or credentials to the clients. In at least some embodiments, thecontrol-plane operations performed at the logging service may includetrimming or archiving portions of the stored transaction state records(element 1914). In some such embodiments, for example, when the amountof storage used for transaction records of a given persistent change logcrosses a threshold, some number of the oldest transaction records maybe copied to a different storage facility (such as a provider networkstorage service, or a slower set of storage devices than are used forthe recent set of transaction records). In another embodiment, theoldest transaction records may simply be discarded. In at least oneembodiment, other control-plane operations may be performed as needed,such as switching between one instance of a persistence change log andanother—e.g., when the first change log reaches a threshold populationof records.

FIG. 20 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction requestreceived from a client, according to at least some embodiments. As shownin element 2001, a logging service's conflict detector may receive atransaction request descriptor of transaction T1, e.g., indicating aconflict check delimiter, a read set, and a write set comprising one ormore writes to respective locations at one or more data stores for whicha persistent change log has been established by the logging service. Theconflict check delimiter may indicate a committed state of one or moresource data stores from which the results of the reads of thetransaction were obtained, and may therefore serve as a committed stateidentifier (CSI). CSIs may also be referred to as “snapshot sequencenumbers” in some environments, as they may correspond to a point-in-timelogical snapshot of the source data stores. A set S1 of transactionrecords stored at the persistent change log may be identified forchecking potential conflicts with the requested transaction (element2004), e.g., using the conflict check delimiter and the sequence numbersof the transaction records stored in the log. Such a set S1 may include,for example, all the records of transactions that have commit sequencenumbers higher than a sequence number indicated in the conflict checkdelimiter in one embodiment.

If a read-write conflict is detected (element 2007), e.g., if the readset of the requested transaction overlaps at least partly with the writeset of one of the transactions of set S1, the transaction T1 may berejected or aborted (element 2022). In some embodiments, hash functionsmay be used to determine whether such overlaps exist—e.g., if the readset hashes to the same value as a write set, a conflict may be assumedto have occurred. In some implementations, an indication or notificationof the rejection may be provided to the client from which thetransaction request was received, enabling the client to retry thetransaction by generating and submitting another request descriptor. Ifa conflict is not detected (as also determined in element 2007), T1 maybe accepted for commit (element 2010). In the depicted embodiment,replication of T1's transaction record may be initiated to persistentstorage, e.g., at a plurality of replication DAG nodes of the log. Insome embodiments, an acceptance sequence number may be assigned to T1when it is accepted for commit, and may be stored together with contentsof at least some of the transaction request descriptor elements in eachreplica. In at least one embodiment, the acceptance sequence number mayserve as a commit sequence number if the transaction eventually getscommitted.

Depending on the data durability needs of the application whosetransactions are being managed, a threshold number of replicas may haveto be stored before the transaction T1's commit is complete. If asufficient number of replicas are saved (as determined in element 2013),the commit may be deemed successful, and the requesting client may benotified in some embodiments regarding the commit completion (element2014). If for some reason the number of replicas that can be saved topersistent storage is below the required threshold (as also detected inelement 2013), the transaction may be aborted/rejected (element 2022).After T1 commits, in the depicted embodiment the write operationsindicated in T1's write set may be applied to the corresponding datastores or data consumers, e.g., by asynchronous write appliers (element2016). In some embodiments, at least one of the write appliers may besynchronous—e.g., a client may be notified that the transaction has beencommitted only after such a synchronous write applier completes thesubset of the transaction's writes for which updates are to be appliedsynchronously. After the updates have been applied, the updated dataelements may be read in response to client read requests received viathe respective data stores' read interfaces (element 2019). In additionto the read interfaces supported by the various registered data stores,in at least some embodiments the persistent change log may itself bequeried directly for transaction record contents, e.g., via aprogrammatic query/read interface of the logging service. In someimplementations, reads directed to the log via such a logging serviceinterface may be able to see the results of write operations morequickly in some cases than reads directed to the data stores, since thedata stores may rely on asynchronous appliers to propagate the writesthat are already present in the log. In some embodiments, synchronousappliers may be used, which propagate writes to the data stores as soonas the transaction is committed at the log. In other embodiments, eachapplier may have a configurable time window within which writes have tobe propagated to the corresponding data store or consumer, so that itbecomes possible to adjust the maximum delay between a transactioncommit and the appearance of the transaction's modified data at the datastores.

FIG. 21 illustrates examples of transaction request descriptors that maybe used to achieve respective special-case consistency objectives,according to at least some embodiments. In one embodiment, clients ofthe logging service may wish to enforce “read-after-write” consistencysemantics, according to which a write becomes visible to all readers assoon as it is committed. To ensure read-after-write consistency, i.e.,to ensure that reads always “see” data immediately after it iscommitted, a client may wish to submit transaction requests even forread-only transactions (as well as for transactions that containwrites). Read-only transaction request descriptor (TRD) 2144, forexample, has a null write set 2106A and a null write payload 2108A, buthas a non-null conflict check delimiter 2102A and a non-null read setdescriptor 2104A. Upon receiving such a read-only transaction requestdescriptor, the conflict detector may check whether an overlap existsbetween the read set indicated in the request and the writes that havebeen committed with sequence numbers higher than the sequence numberindicated in the conflict-check delimiter. If a conflict is detected,the read-only transaction may be rejected, thus disallowing reads tolocations to which writes may have been committed after the conflictcheck delimiter was generated, even though the requested transactiondoes not include any writes dependent on those reads.

In at least some embodiments, write-only transaction requests may besubmitted to the logging service under certain circumstances. For someapplications, it may be the case that the client does not wish toenforce read-write consistency checks, at least during some time periodsor for some data stores. Instead, the client may wish to have somewrites accepted unconditionally for commit during such time periods.Accordingly, a transaction request descriptor 2145 that has a null readset 2104B and/or a null conflict check delimiter 2102B may be submitted,with a non-null write set descriptor 2106B and a non-null write payload2108B. Such write-only requests may be submitted, for example, when adata store or object is being initially populated, or if only one writerclient is known to be submitting requests during some time period.

As mentioned earlier, in some embodiments asynchronous write appliersmay be used to propagate contents of committed writes from thepersistent change log to various data stores or data consumers. As aresult of the asynchronous nature of the write propagation, it may bethe case at some points of time that a set of committed writes has notyet been propagated to their intended data stores. In at least oneembodiment, it may be possible to flush such un-applied writes usingwrite-only transactions. For example, if a particular write applier WA1is configured to have no more than N un-applied writes outstanding to agiven data store DS1, a client may submit a write-only transactionrequest descriptor such as TRD 2145 directed to a special write locationWL1 in DS1, where WL1 is used specifically or primarily for flushingoutstanding committed writes. In some cases, such a TRD may not need tohave any write payload at all (e.g., write payload 2108B may be set tonull). When such a write-apply-flushing transaction request is accepted,a new pending committed write may be added to the log and to WA1's queueof outstanding requests. As the length of the queue grows, WA1 may haveto start applying the earlier-committed writes in the queue to meet itsrequirement of no more than N un-applied writes. In some embodiments,such write-apply-flushing requests may be submitted periodically, e.g.,once every second, to ensure that committed writes do not remain pendingfor too long. When a write-apply-flushing transaction's committed writereaches the head of an applier's queue, in some implementations aphysical write need not be performed; instead, for example, the appliermay simply send the commit sequence number corresponding to thetransaction to the destination data store as an indicator of themost-recently “applied” write.

For some applications, clients may wish to enforce strict serialization,during at least for some time periods. That is, only one(write-containing) transaction may be allowed to proceed at a time,regardless of whether any conflicts exist between the data read duringthe transaction and writes that may have been committed since thetransaction preparation was initiated. In such a scenario, a client maysubmit a strict-serialization transaction request descriptor 2146 to thelogging service, with its read set descriptor 2104C indicating theentire contents of all the data sets used by the application. In oneimplementation in which a hash value is used as an indicator of thelocations read/written, and a bit-wise comparison with write set entriesis used to detect conflicts, for example, a hash value included in readset descriptor 2402C may be set to a sequence of “1”s (e.g.,“1111111111111111” for a 16-bit hash value). If any write-containingtransactions have been committed with CSNs greater than the conflictcheck delimiter 2102C of such a TRD 2146, the transaction correspondingto TRD 2146 may be rejected. Thus, the writes indicated by write setdescriptor 2106C and write payload 2108C would only be committed if noother write has been committed (regardless of the location of such awrite) in the conflict check interval indicated by the descriptor.

De-Duplication and Sequencing Constraints

In some embodiments, clients of the logging service may wish to ensurethat duplicate entries are not written to one or more data stores. Inone such embodiment, in addition to performing read-write conflictdetection as described above, the logging service may also have toenforce a de-duplication requirement indicated in the transactionrequest. FIG. 22 illustrates an example of enforcing a de-duplicationconstraint associated with a transaction request received at a log-basedtransaction manager, according to at least some embodiments. As shown,the transaction request descriptor 2244 comprises a read-write conflictcheck delimiter 2212, a read-set descriptor 2214, a write-set descriptor2216, and a logical constraint delimiter 2218. The write payload of TRD2244 is not shown in FIG. 22. The logical constraint descriptor 2218includes LC-type field 2219 indicating that it represents ade-duplication constraint, de-duplication check delimiter 2220, andexclusion signature(s) 2222 in the depicted embodiment.

In order to determine whether to accept the requested transaction, thelogging service may have to perform two types of checks in the depictedembodiment: one for detecting read-write conflicts, and one fordetecting duplicates. The commit records 2252 in the persistent changelog 2210 may each include respective commit sequence numbers (CSNs2204), write set descriptors (WSDs) 2205, and de-duplication signatures(DDSs) 2206 in the depicted embodiment. To determine whether aread-write conflict has occurred, the logging service may identify CRset 2209, starting at a sequence number corresponding to read-writeconflict check delimiter 2212 and ending with the most-recent commitrecord 2252F, whose write sets are to be evaluated for overlaps with therequested transaction's read set descriptor 2214. If a read-writeconflict is detected (i.e., if such an overlap exists), the requestedtransaction may be rejected as described earlier.

To determine whether the requested transaction's write(s) representduplicates, another CR set 2259 may be identified in the depictedembodiment starting at a sequence number corresponding to de-duplicationcheck delimiter 2220, and ending at the most recent commit record 2252F.For each of the commit records in CR set 2259, the logging service maycheck whether any of the de-duplication signatures stored in the commitrecord match the exclusion signature(s) 2222 of the requestedtransaction. A duplicate may be detected if such a match is found, andthe requested transaction may be rejected in such a scenario even if noread-write conflicts were detected. If duplication is not detected, andif no read-write conflicts are detected, the transaction may be acceptedfor commit.

In at least some embodiments, a de-duplication signature 2206 mayrepresent the data items written by the corresponding transaction in adifferent way (e.g., with a hash value generated using a different hashfunction, or with a hash value stored using more bits) than the writeset descriptors. Such different encodings of the write set may be usedfor de-duplication versus read-write conflict detection for any of anumber of reasons. For example, for some applications, clients may bemuch more concerned about detecting duplicates accurately than they areabout occasionally having to resubmit transactions as a result of afalse-positive read-write conflict detection. For such applications, theacceptable rate of errors in read-write conflict detection may thereforebe higher than the acceptable rate of duplicate-detection errors.Accordingly, in some implementations, cryptographic-strength hashfunctions whose output values take 128 or 256 bits may be used forde-duplication signatures, while simpler hash functions whose output isstored using 16 or 32 bits may be used for the write signatures includedin the WSDs. In some scenarios, de-duplication may be required for asmall subset of the data stores being used, while read-write conflictsmay have to be checked for a much larger set of transactions. In suchcases, storage and networking resource usage may be reduced by usingsmaller WDS signatures than de-duplication signatures in someembodiments. It may also be useful to logically separate the read-writeconflict detection mechanism from the de-duplication detection mechanisminstead of conflating the two for other reasons—e.g., to avoid confusionamong users of the logging service, to be able to support separatebilling for de-duplication, and so on.

In other embodiments, the write set descriptors may be used for bothread-write conflict detection and de-duplication purposes (e.g.,separate exclusion signatures may not be used). Similarly, in someembodiments, the same sequence number value may be used as a read-writeconflict check delimiter and a de-duplication check delimiter—i.e., thesets of commit records examined for read-write conflicts may also bechecked for duplicates. In at least one embodiment, de-duplication maybe performed by default, e.g., using the write-set descriptors, withoutthe need for inclusion of a logical constraint descriptor in thetransaction request descriptor.

For some applications, clients may be interested in enforcing a commitorder among specified sets of transactions—e.g., a client that submitsthree different transaction requests for transactions T1, T2 and T3respectively may wish to have T1 committed before T2, and T3 to becommitted only after T1 and T2 have both been committed. Such commitsequencing constraints may be enforced using a second type of logicalconstraint descriptor in some embodiments. FIG. 23 illustrates anexample of enforcing a sequencing constraint associated with atransaction request received at a log-based transaction manager,according to at least some embodiments. As shown, the transactionrequest descriptor 2344 comprises a read-write conflict check delimiter2312, a read-set descriptor 2314, a write-set descriptor 2316, and adifferent type of logical constraint delimiter 2318 than logicaldescriptor 2218 of FIG. 22. The write payload of TRD 2344 is not shownin FIG. 23. The logical constraint descriptor 2318 includes LC-typefield 2319 indicating that it represents a sequencing constraint, asequencing check delimiter 2220, and required sequencing signatures2322A and 2322B corresponding to transactions T1 and T2 respectively inthe depicted embodiment. The logical constraint descriptor 2318 may beincluded in TRD 2344 to ensure that the requested transaction iscommitted only if both transactions T1 and T2 (represented by sequencingsignatures 2322A and 2322B) have been committed earlier.

In order to determine whether to accept the requested transaction, thelogging service may once again have to perform two types of checks inthe example illustrated in FIG. 23: one for detecting read-writeconflicts, and one for ensuring that the transactions T1 and T2 havebeen committed. The commit records 2352 in the persistent change log2310 may each include respective commit sequence numbers (CSNs 2304),write set descriptors (WSDs) 2305, and sequencing signatures 2306 in thedepicted embodiment. To determine whether a read-write conflict hasoccurred, as before, the logging service may identify CR set 2309,starting at a sequence number corresponding to read-write conflict checkdelimiter 2312 and ending with the most-recent commit record 2352F,whose write sets are to be evaluated for overlaps with the requestedtransaction's read set descriptor 2314. If a read-write conflict isdetected (i.e., if such an overlap exists), the requested transactionmay be rejected.

To determine whether the requested transaction's sequencing constraintsare met, another CR set 2359 may be identified in the depictedembodiment starting at a sequence number corresponding to sequencingcheck delimiter 2320, and ending at the most recent commit record 2352F.The logging service may have to verify that respective commit recordswith sequencing signatures that match required signatures 2322A and2322B exist within CR set 2359. If at least one of the requiredsignatures 2322 is not found in CR set 2259, the sequencing constraintmay be violated and the requested transaction may be rejected, even ifno read-write conflicts were detected. If both sequencing signatures arefound in CR set 2359, and if no read-write conflicts are detected, thetransaction may be accepted for commit.

The sequencing signatures stored within the CRs 2352 (and in the TRD2344) may be generated using a variety of techniques in differentembodiments. In some embodiments, they may be generated from the writesets of the transactions; in other embodiments, sequencing signaturesmay be based at least in part on other factors. For example, theidentity of the requesting client may be encoded in the sequencingsignatures in addition to the write signatures in some embodiments, theclock time at which the transaction was requested may be encoded in thesequencing signatures, or an indication of the location from which thetransaction was requested may be encoded, and so on. Similarconsiderations as described above regarding the use of differenttechniques for representing sequencing signatures than write setsignatures may apply in some embodiments. Accordingly, in someembodiments, a different technique may be used to generate sequencingsignatures than is used for generating write set descriptor contents,even if both the sequencing signatures and the write set signatures arederived from the same underlying write locations. For example, adifferent hash function or a different hash value size may be used. Inother embodiments, however, the write set descriptors may be used forboth read-write conflict detection and sequencing enforcement purposes(e.g., separate sequencing signatures may not be used). Similarly, insome embodiments, the same sequence number value may be used as aread-write conflict check delimiter and a sequencing checkdelimiter—i.e., the sets of commit records examined for read-writeconflicts may also be checked for sequencing. In some cases arbitrarynumbers or strings unrelated to write sets may be used as sequencingsignatures. In at least one embodiment, a constraint descriptor may notinclude an LC-type field; instead, the type of a constraint may beindicated by the position of the constraint descriptor within thetransaction request. In some embodiments, a “required” flag may beassociated with sequencing signatures, and an “excluded” flag may beassociated with a de-duplication signature, instead of using LC-typefields, for example. As mentioned earlier in the context of read-writeconflict check delimiters, in some embodiments CSN upper bounds may alsobe specified within a transaction request descriptor to indicate therange of commit records that should be examined for constraint checking,instead of just specifying the CSN lower bound.

In some embodiments, more complex sequencing constraints may be enforcedthan are illustrated in FIG. 23. For example, instead of simplyrequesting the logging service to verify that both transactions T1 andT2 must have been committed (in any order) prior to the requestedtransaction's commit, a client may be able to request that T1 must havebeen committed prior to T2. Similarly, in some embodiments a client maybe able to request negative ordering requirements: e.g., that some setof transactions {T1, T2, Tk} should have been committed before therequested transaction in some specified order (or in any order), andalso that some other set of transactions {Tp, Ts} should not have beencommitted.

In FIG. 22 and FIG. 23, a single type of logical constraint wasindicated in the transaction requests shown. In some embodiments,clients may wish to enforce several different types of logicalconstraints on various transactions. FIG. 24 illustrates an example of atransaction request descriptor comprising multiple logical constraintdescriptors, according to at least some embodiments. One sequencingconstraint is to be applied, and one de-duplication constraint is to beapplied for the same requested transaction represented by transactiondescriptor 2444. In the depicted embodiment, the read and write setdescriptors comprise 32-bit (4-byte) hash values for each data item reador written. For example, respective 4-byte read hash signatures 2464Aand 2464B may represent two data item locations in the read setdescriptor 2404, and respective 4-byte write hash signatures 2465A and2465B may be included in write set descriptor 2406 to represent twolocations targeted for writes if the transaction is committed.Read-write conflict check delimiter 2402 is to be used to select thelower bound of a range of sequence numbers in the persistent change logwhose commit records are to be checked for read-write conflicts with therequested transaction.

Transaction request descriptor 2444 may also include a sequencingconstraint descriptor 2408A and a de-duplication constraint descriptor2408B in the depicted embodiment. Sequencing constraint descriptor 2408Amay include a constraint type field 2409A, a sequencing check delimiter2410, and one or more required sequencing signatures such as 2412A and2412B corresponding to transactions whose commits must have beencompleted for the requested transaction to be accepted. De-duplicationconstraint descriptor 2408B may include a constraint type field 2409B, adeduplication check delimiter 2420, and a deduplication exclusionsignature 2422.

As shown, in the depicted embodiment, the required sequencing signatures2412A, 2412B and the de-duplication signature 2422 may respectivelycomprise 128-bit (16-byte) hash signatures 2466A, 2466B and 2467. Thus,the logical constraint signatures may each occupy four times as manybits as are used per data item for read and write set signatures in thedepicted example, which may help reduce the number of hash collisionsfor the logical constraint-related comparisons relative to thecomparisons performed for read-write conflict detection. In someembodiments, a cryptographic hash function such as MD5 may be used forthe sequencing and/or the de-duplication signatures. The use ofcryptographic hash functions may help reduce the probability of errorsin evaluating logical constraints to near zero in at least some suchembodiments. Although a reasonably low rate of transaction rejectionsbased on false positive hash collisions (e.g., on a false positiveread-write conflict detection) may be acceptable, at least some clientsmay be much more concerned about avoiding the acceptance of atransaction due to a false positive hash collision (e.g., in the case ofcommit sequencing), and the use of cryptographic-strength hash functionsmay help to avoid such erroneous transaction acceptances. In someimplementations, clients may be able to select hash functions to be usedfor duplicate detection and/or for sequencing purposes. Different hashfunctions and/or hash value lengths may be used for de-duplicationsignatures, sequencing signatures and/or read or write signatures insome embodiments than shown in FIG. 24—for example, the de-duplicationand sequencing signatures may differ in size. In at least someembodiments, the addresses of data items read or written may be used forread/write set signatures, deduplication and/or sequencing signatures,e.g., instead of using hash values generated from the addresses. In oneembodiment, the de-duplication and/or write signatures may be derivedfrom the write payload in addition to, or instead of, from the locationsto which data is written.

Additional logical constraints may also be specified in the transactionrequest descriptor in some embodiments, such as data integrity/validityconstraints or commit-by deadline constraints. An example data integrityor validity constraint may require, for example, that a particular valueV1 may only be stored in a data store DS1 if a different value V2 isalready stored, either in DS1 or in some other data store. A datavalidity constraint may define acceptable ranges (either unconditional,or conditioned on the values stored in specified data store locations)for specified data types or data items to be stored. Commit-byconstraints may indicate deadlines by which a transaction's commit is tobe completed, with the intent that the transaction should be abandonedor aborted if the deadline is not met.

FIG. 25 is a flow diagram illustrating aspects of operations that may beperformed at a logging service in response to a transaction request thatindicates one or more logical constraints, according to at least someembodiments. In the depicted embodiment, a given transaction's commitrequirements may include concurrency control requirements (e.g., arequirement that no read-write conflicts of the kinds described aboveare found) as well as logical constraint requirements. Bothde-duplication and sequencing logical constraints may be supported for asingle transaction (other logical constraints may also be supported, butonly the operations pertaining to de-duplication and sequencing areshown in FIG. 25) in at least some embodiments. As shown in element2501, a transaction request descriptor that includes one or more logicalconstraint descriptors of a transaction T1 may be received at a conflictdetector associated with a particular persistent change log instance ofa logging service. For each logical descriptor, a corresponding checkdelimiter may be specified in the depicted embodiment, to be used toselect the set of commit records to be analyzed to determine whether thelogical constraint is met or violated. Respective sets of one or moresignatures may also be specified for each logical constraint. The readand write sets of the requested transaction may also be indicated,together with a read-write conflict check delimiter. As mentionedearlier, in some embodiments, the same delimiter may be used for one ormore logical constraints as that used for checking read-write conflicts.Also, in at least one embodiment, separate signatures may not berequired for logical constraints; instead, for example, the write setsignatures may be used as de-duplication and/or sequencing signatures.

Using the read-write conflict check delimiter, a first set of commitrecords CRS1 to be analyzed may be identified in the depictedembodiment. Such a set may, for example, comprise those commit recordswhose sequence numbers lie in a range starting at the read-writeconflict check delimiter, up to the sequence number of the mostrecently-stored commit record (or up to a different upper boundindicated in the transaction request). If a read-write conflict isdetected (element 2504) (e.g., if the write sets of any of the commitrecords of CRS1 overlaps with the read set of the requestedtransaction), the transaction may be rejected/aborted (element 2531).Checking for read-write conflicts may also be referred to herein asverifying that the requested transaction meets concurrency controlrequirements. In some embodiments, the client from which the transactionrequest was received may be notified that the transaction has beenaborted.

If a read-write conflict is not detected (also in operationscorresponding to element 2504), each of the logical constraintsindicated by the corresponding descriptors may be checked in sequence inthe depicted embodiment. The next logical constraint descriptor in thesequence may be examined, and a new commit record set CRS-k may beselected for constraint analysis based on the check delimiter associatedwith the constraint (element 2507). For example, CRS-k may include allthe commit records with sequence numbers in the range starting with thedelimiter and ending at the highest recorded commit sequence number (orup to a different upper bound indicated in the transaction request). Theanalysis to be performed may depend on the type of the logicalconstraint descriptor. If a de-duplication constraint is to be checked,and if a duplicate is found by comparing the de-duplication signaturesof CDR-k and the requested transaction (element 2510), the transactionmay also be rejected/aborted (element 2531). If the constraint is ade-duplication constraint and no duplicate is found (as also detected inelement 2510), and if more logical constraints remain to be analyzed,the next logical constraint descriptor may be examined and theoperations corresponding to elements 2507 onwards may be repeated forthe next logical descriptor.

If the constraint descriptor indicates a sequencing constraintindicating one or more required signatures of committed transactions,the CRS-k for the sequencing constraint may be examined to ensure thatthe required signatures have in fact been stored for transactions whosecommits have completed. If the commit records of the requiredtransactions are not found (as detected in element 2513), the requestedtransaction may also be aborted/rejected (element 2531). If the commitrecords of the required transactions are found (also in operationscorresponding to element 2513), the sequencing constraint processing maybe complete. As in the case of read-write conflict detection, logicalconstraint checking may also be performed using hash functions for thecomparisons in at least some embodiments, thus avoiding the overhead ofscanning the commit record sets. If any logical constraint descriptorsremain (element 2516), they may be examined in turn. If no logicalconstraint descriptors remain (as also detected in element 2516), thetransaction may be accepted for commit. A procedure to save thetransaction's commit records in persistent storage may be initiated inthe depicted embodiment (element 2519), e.g., at several nodes of areplication DAG. If the replication succeeds (e.g., if a sufficientnumber of copies of the commit record are stored successfully atrespective storage devices) (as detected in element 2522), thetransaction's commit may be considered complete. If for some reason therequired number of replicas is not stored, the transaction may still berejected/aborted (element 2531). In some embodiments, a notificationthat the transaction has been successfully committed may be transmittedto the requesting client (element 2525).

In some embodiments, operations to check more than one logicalconstraint may be performed in parallel instead. In one embodiment, anycombination of the read-write conflict check and the logical constraintchecks may be performed in parallel. In some embodiments, responsesregarding each of the logical constraints indicated may be provided tothe requesting client, even if one or more of the constraints are notmet. For example, in the case of a transaction request with ade-duplication constraint and a sequencing constraint, the sequencingconstraint may be checked even if the de-duplication constraint isn'tmet, and the results of the evaluation of both constraints may beprovided to the client. In some implementations, clients may be able toexplicitly request that a specified subset or all of the logicalconstraints of a given transaction request are to be checked.

It is noted that in various embodiments, operations other than thoseillustrated in the flow diagram of FIGS. 6, 7, 8, 9, 10, 12, 13, 14, 19,20 and 25 may be used to implement at least some of the techniques ofapplication state management, coordinated suspension, concurrencycontrol and logical constraint management described above. Some of theoperations shown may not be implemented in some embodiments, may beimplemented in a different order, or in parallel rather thansequentially (as indicated above with respect to FIG. 25).

Use Cases

The techniques described above, of managing application state changesusing replication DAGs, including log-based transaction management, maybe useful in a variety of embodiments. As more and more organizationsmigrate their computing to provider network environments, a largervariety of distributed storage applications with respective consistencysemantics and respective interfaces has been developed. Some largeapplications may span multiple data store instances, and the replicationDAGs and log-based transaction management techniques may represent aunified, flexible, scalable, and highly-available approach todistributed storage application management. The ability of thereplication DAG nodes to make progress on application state transitionseven though the respective views of the DAG configuration may at leasttemporarily diverge may reduce or eliminate at least some of the“stop-the-world” pauses in handling application requests that may ariseif less dynamic replication techniques are used. Log-based transactionmanagement may not only allow cross-data-store transactions (as well asmulti-item transactions for data stores that may not support atomicmulti-write transactions), but may also facilitate features such asautomated query response generation, snapshot generation, and the like.Entirely new ways of performing data analysis across multiple datastores may be enabled using the logging service's own read interfaces.

In some provider network environments, log-based transaction managementvia replication DAGs may be used to store control-plane configurationinformation of another network-accessible service implemented at theprovider network, such as a virtualized computing service, a storageservice, or a database service. In such scenarios, the transactionsmanaged using the log may represent changes to the configurations ofvarious resources of the network-accessible service (such as computeinstances or virtualization hosts in the case of a virtual computingservice).

Illustrative Computer System

In at least some embodiments, a server that implements a portion or allof one or more of the technologies described herein, including thetechniques to implement the various components of a replication DAGand/or a logging service for transaction management may include ageneral-purpose computer system that includes or is configured to accessone or more computer-accessible media. FIG. 26 illustrates such ageneral-purpose computing device 9000. In the illustrated embodiment,computing device 9000 includes one or more processors 9010 coupled to asystem memory 9020 (which may comprise both non-volatile and volatilememory modules) via an input/output (I/O) interface 9030. Computingdevice 9000 further includes a network interface 9040 coupled to I/Ointerface 9030.

In various embodiments, computing device 9000 may be a uniprocessorsystem including one processor 9010, or a multiprocessor systemincluding several processors 9010 (e.g., two, four, eight, or anothersuitable number). Processors 9010 may be any suitable processors capableof executing instructions. For example, in various embodiments,processors 9010 may be general-purpose or embedded processorsimplementing any of a variety of instruction set architectures (ISAs),such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitableISA. In multiprocessor systems, each of processors 9010 may commonly,but not necessarily, implement the same ISA. In some implementations,graphics processing units (GPUs) may be used instead of, or in additionto, conventional processors.

System memory 9020 may be configured to store instructions and dataaccessible by processor(s) 9010. In at least some embodiments, thesystem memory 9020 may comprise both volatile and non-volatile portions;in other embodiments, only volatile memory may be used. In variousembodiments, the volatile portion of system memory 9020 may beimplemented using any suitable memory technology, such as static randomaccess memory (SRAM), synchronous dynamic RAM or any other type ofmemory. For the non-volatile portion of system memory (which maycomprise one or more NVDIMMs, for example), in some embodimentsflash-based memory devices, including NAND-flash devices, may be used.In at least some embodiments, the non-volatile portion of the systemmemory may include a power source, such as a supercapacitor or otherpower storage device (e.g., a battery). In various embodiments,memristor based resistive random access memory (ReRAM),three-dimensional NAND technologies, Ferroelectric RAM, magnetoresistiveRAM (MRAM), or any of various types of phase change memory (PCM) may beused at least for the non-volatile portion of system memory. In theillustrated embodiment, program instructions and data implementing oneor more desired functions, such as those methods, techniques, and datadescribed above, are shown stored within system memory 9020 as code 9025and data 9026.

In one embodiment, I/O interface 9030 may be configured to coordinateI/O traffic between processor 9010, system memory 9020, and anyperipheral devices in the device, including network interface 9040 orother peripheral interfaces such as various types of persistent and/orvolatile storage devices. In some embodiments, I/O interface 9030 mayperform any necessary protocol, timing or other data transformations toconvert data signals from one component (e.g., system memory 9020) intoa format suitable for use by another component (e.g., processor 9010).In some embodiments, I/O interface 9030 may include support for devicesattached through various types of peripheral buses, such as a variant ofthe Peripheral Component Interconnect (PCI) bus standard or theUniversal Serial Bus (USB) standard, for example. In some embodiments,the function of I/O interface 9030 may be split into two or moreseparate components, such as a north bridge and a south bridge, forexample. Also, in some embodiments some or all of the functionality ofI/O interface 9030, such as an interface to system memory 9020, may beincorporated directly into processor 9010.

Network interface 9040 may be configured to allow data to be exchangedbetween computing device 9000 and other devices 9060 attached to anetwork or networks 9050, such as other computer systems or devices asillustrated in FIG. 1 through FIG. 25, for example. In variousembodiments, network interface 9040 may support communication via anysuitable wired or wireless general data networks, such as types ofEthernet network, for example. Additionally, network interface 9040 maysupport communication via telecommunications/telephony networks such asanalog voice networks or digital fiber communications networks, viastorage area networks such as Fibre Channel SANs, or via any othersuitable type of network and/or protocol.

In some embodiments, system memory 9020 may be one embodiment of acomputer-accessible medium configured to store program instructions anddata as described above for FIG. 1 through FIG. 25 for implementingembodiments of the corresponding methods and apparatus. However, inother embodiments, program instructions and/or data may be received,sent or stored upon different types of computer-accessible media.Generally speaking, a computer-accessible medium may includenon-transitory storage media or memory media such as magnetic or opticalmedia, e.g., disk or DVD/CD coupled to computing device 9000 via I/Ointerface 9030. A non-transitory computer-accessible storage medium mayalso include any volatile or non-volatile media such as RAM (e.g. SDRAM,DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc., that may be included in someembodiments of computing device 9000 as system memory 9020 or anothertype of memory. Further, a computer-accessible medium may includetransmission media or signals such as electrical, electromagnetic, ordigital signals, conveyed via a communication medium such as a networkand/or a wireless link, such as may be implemented via network interface9040. Portions or all of multiple computing devices such as thatillustrated in FIG. 26 may be used to implement the describedfunctionality in various embodiments; for example, software componentsrunning on a variety of different devices and servers may collaborate toprovide the functionality. In some embodiments, portions of thedescribed functionality may be implemented using storage devices,network devices, or special-purpose computer systems, in addition to orinstead of being implemented using general-purpose computer systems. Theterm “computing device”, as used herein, refers to at least all thesetypes of devices, and is not limited to these types of devices.

CONCLUSION

Various embodiments may further include receiving, sending or storinginstructions and/or data implemented in accordance with the foregoingdescription upon a computer-accessible medium. Generally speaking, acomputer-accessible medium may include storage media or memory mediasuch as magnetic or optical media, e.g., disk or DVD/CD-ROM, volatile ornon-volatile media such as RAM (e.g. SDRAM, DDR, RDRAM, SRAM, etc.),ROM, etc., as well as transmission media or signals such as electrical,electromagnetic, or digital signals, conveyed via a communication mediumsuch as network and/or a wireless link.

The various methods as illustrated in the Figures and described hereinrepresent exemplary embodiments of methods. The methods may beimplemented in software, hardware, or a combination thereof. The orderof method may be changed, and various elements may be added, reordered,combined, omitted, modified, etc.

Various modifications and changes may be made as would be obvious to aperson skilled in the art having the benefit of this disclosure. It isintended to embrace all such modifications and changes and, accordingly,the above description to be regarded in an illustrative rather than arestrictive sense.

What is claimed is:
 1. A system, comprising: one or more computingdevices configured to: instantiate a state replication group (SRG)comprising a plurality of nodes to replicate state information of aparticular application, wherein at least some nodes of the SRG store arespective commit record set of the application, wherein each commitrecord of a commit record set comprises a commit sequence number (CSN)indicative of an order in which a state transition of the applicationwas committed relative to other state transitions, and wherein the SRGcomprises a committer node configured to commit requested statetransitions; determine, at the committer node, in response to adetection that a threshold condition has been met, that state transitionprocessing operations of the SRG are to be suspended; transmit, from thecommitter node to a fault-tolerant configuration manager of the SRG, asuspend request indicating a highest commit sequence number (HCSN) amongthe CSNs of the commit record set stored at the committer node; transmita respective suspend command from the configuration manager to one ormore other nodes of the SRG including a second node, wherein the suspendcommand indicates the HCSN; pause, in response to receiving a suspendcommand from the configuration manager, state transition processingoperations at the second node; verify, by the second node, that thesecond node's commit record set includes a commit record with the HCSN;and defer, by the committer node and the second node, further processingof state transition operations until a reactivation message is receivedfrom the configuration manager.
 2. The system as recited in claim 1,wherein the detection that the threshold condition has been metcomprises a determination that a metric is outside an acceptable range,wherein the metric comprises one or more of: (a) a number of activenodes of the SRG, (b) a rate of SRG configuration-delta messagesreceived from the fault-tolerant configuration manager at a selectednode of the SRG, or (c) a number of client connections to a selectednode of the SRG.
 3. The system as recited in claim 1, wherein the one ormore computing devices are further configured to: determine, by thesecond node, in response to receiving the suspend command from thefault-tolerant configuration manager, that the commit record set at thesecond node does not include a commit record comprising HCSN; andrequest, by the second node from the committer node, one or more commitrecords including a commit record comprising the HCSN.
 4. The system asrecited in claim 1, wherein the second node comprises a first thread ofexecution at a particular host wherein the one or more computing devicesare further configured to: restart the first thread of execution afterverifying that the commit record comprising the HCSN is stored in thesecond node's commit record set.
 5. The system as recited in claim 4,wherein the one or more computing devices are further configured to:determine, by the fault-tolerant configuration manager after the suspendcommand has been sent, that a number of available SRG nodes whose commitrecords have been updated up to the HCSN exceeds a threshold; andtransmit, by the fault-tolerant configuration manager to each node whosecommit record set has been updated up to the HCSN, a respectivere-activation request including a representation of a targetedconfiguration of the SRG.
 6. A method, comprising: performing, by one ormore computing devices: determining that state transition processingoperations of a state replication group (SRG) comprising a plurality ofnodes are to be suspended, wherein the SRG is designated to replicatestate information comprising a respective commit record set of anapplication, wherein each commit record of the commit record set has anassociated commit sequence number (CSN) indicative of an order in whichthe corresponding state transition of the application was committed atthe SRG; identifying a target CSN up to which commit record sets of oneor more nodes of the SRG are to be synchronized; transmitting arespective suspend command from a configuration manager of the SRG tothe one or more other nodes of the SRG, wherein the suspend commandindicates the target CSN; verifying, by a particular node of the one ormore other nodes, that a commit record corresponding to the target CSNis stored in the particular node's commit record set; and suspendingstate transition processing operations by the particular node.
 7. Themethod as recited in claim 6, wherein said determining that the statetransition processing operations of the SRG are to be suspended isresponsive to a detection that a metric is outside an acceptable range,wherein the metric comprises one or more of: (a) a number of activenodes of the SRG, (b) a rate of SRG configuration-delta messagesreceived from the configuration manager at a selected node of the SRG,or (c) a number of client connections to a selected node of the SRG. 8.The method as recited in claim 6, wherein said determining that thestate transition processing operations of the SRG are to be suspended isperformed at a committer node of the SRG, wherein the committer node isresponsible for committing one or more requested state transitions ofthe application, and wherein the target CSN is the highest CSN among theCSNs of the commit record set of the committer node.
 9. The method asrecited in claim 6, further comprising performing, by the one or morecomputing devices prior to said verifying: determining, by theparticular node, in response to receiving a suspend command from theconfiguration manager, that the commit record set at the second nodedoes not include a commit record corresponding to the target CSN; andrequesting, by the particular node from a different node of the SRG, oneor more commit records including a commit record corresponding to thetarget CSN.
 10. The method as recited in claim 6, wherein the particularnode comprises a first thread of execution at a particular host, furthercomprising performing, by the one or more computing devices: restarting,subsequent to said suspending, the first thread of execution.
 11. Themethod as recited in claim 6, further comprising performing, by the oneor more computing devices: receiving, at the configuration manager fromthe particular node subsequent to said verifying, a confirmation thatthe particular node has updated its commit record set up to the targetCSN; and including, by the configuration manager in a collection ofup-to-date nodes of the SRG, the particular node.
 12. The method asrecited in claim 11, further comprising performing, by the one or morecomputing devices: receiving, at the configuration manager subsequent tosaid suspending, respective messages from a second plurality of nodes ofthe SRG indicating that the respective nodes are available for service,wherein the second plurality of nodes includes a committer node, theparticular node, and a third node; determining, by the configurationmanager using the collection of up-to-date nodes, that the third node'scommit record set does not include a commit record corresponding to thetarget CSN; and transmitting, by the configuration manager to the thirdnode, an indication of the target CSN.
 13. The method as recited inclaim 12, further comprising performing, by the one or more computingdevices: receiving, at the configuration manager, a confirmation thatthe third node's commit record set has been updated up to the targetCSN; determining, by the configuration manager that a number ofavailable SRG nodes whose commit records have been updated up to thetarget CSN exceeds a threshold; and transmitting, by the configurationmanager to each node whose commit record sets have been updated up tothe target CSN, a respective re-activation request including arepresentation of a targeted configuration of the SRG.
 14. The method asrecited in claim 6, wherein the plurality of nodes of the SRG comprise adirected acyclic graph that includes a replication pathway from anacceptor node to a committer node, further comprising performing, by theone or more computing devices: receiving, at the acceptor node prior tosaid determining that the state transition processing operations are tobe suspended, a request from a client to commit a particular statetransition of the application; storing, at the acceptor node, a recordindicating that the particular state transition has been accepted forreplication; propagating, from the second node via the replicationpathway to the committer node, the request to commit the particularstate transition; determining, by the committer node, that a number ofnodes of the SRG at which a respective record indicative of theparticular state transition has been stored is above a replicationthreshold, and storing, at the committer node, a commit recordcorresponding to the particular state transition.
 15. The method asrecited in claim 6, wherein the application comprises one of: a databaseservice, a logging service, or a control-plane component of a providernetwork service.
 16. A non-transitory computer-accessible storage mediumstoring program instructions that when executed on one or moreprocessors: determine a target commit sequence number (CSN) to be usedto synchronize state information pertaining to a particular applicationamong a plurality of nodes of a state replication group (SRG) prior to asuspension of application state transition processing operations at theSRG, wherein the plurality of nodes includes a first node and a secondnode, wherein each node of the first and second nodes stores arespective commit record set of the particular application, and whereineach commit record of the set has an associated respective CSNindicative of an order in which the corresponding state transition wascommitted at the SRG; store, by a configuration manager of the SRG at apersistent storage device, the target CSN; transmit, from theconfiguration manager to at least one node of the first node and thesecond node, a respective suspend command indicating the target CSN; andin response to an indication received at the configuration manager that,subsequent to a respective suspension of operations at the first nodeand the second node, the first node and the second node are availablefor resumption of operations, verify that a number of available nodes ofthe SRG whose commit record sets include a commit record correspondingto the target CSN exceeds a threshold; and transmit a re-activationmessage to at least a subset of available nodes whose commit record setsinclude a commit record corresponding to the target CSN.
 17. Thenon-transitory computer-accessible storage medium as recited in claim16, wherein the instructions when executed at the one or moreprocessors: receive a request to suspend the application statetransition processing operations from the first node, wherein the firstnode is a committer node responsible for committing a requested statetransition, and wherein the request comprises the target CSN.
 18. Thenon-transitory computer-accessible storage medium as recited in claim16, wherein the instructions when executed at the one or moreprocessors: determine to suspend the application state transitionprocessing operations in response to a detection that a metric isoutside an acceptable range, wherein the metric comprises one or moreof: (a) a number of active nodes of the SRG, (b) a rate of SRGconfiguration-delta messages received from the configuration manager ata selected node of the SRG, or (c) a number of client connections to aselected node of the SRG
 19. The non-transitory computer-accessiblestorage medium as recited in claim 16, wherein the plurality of nodes ofthe SRG comprise a directed acyclic graph.
 20. The non-transitorycomputer-accessible storage medium as recited in claim 16, wherein theinstructions when executed at the one or more processors utilize aconsensus protocol to determine that the state transition processingoperations of the SRG are to be suspended.